各位好,目前我使用 Laravel 當作 API Server 的開發,爬過很多關於 RESTful 的文章,如果是 resource 確定的 crud 很容易處理,舉例來說如果是使用者 > 文章 > 留言
controller name
UserArticleCommentController.php
網址會是 GET www.example.com/users/{user_id}/articles/{article_id}/comments
但常常會有規格外的東西就會比較苦惱,我知道這沒有一定自己公司說好就可以遵守,但還是想聽聽看有相關經驗的朋友可以提供一下想法,下面開始舉例。
場景一,建立 widget:
我今天要提供前端三隻 API 資料給前端的 widget 用,像是 login-records、votes、stars,這三個名稱以及 widget 都沒有所謂的 resource 概念,每一隻都是多張表整理出來的結果,那檔案跟網址命名該怎麼做才好。
1.1
WidgetController.php
function getLoginRecord()
function getVotes()
function getStars
1.2
WidgetLoginRecordController.php
function index()
WidgetVoteController.php
function index()
WidgetStarController.php
function index()
1.3
Widget/LoginRecordController.php
function index()
Widget/VoteController.php
function index()
Widget/StartController.php
function index()
如果以跟一般 RESTful resource 安排一樣的話,會是 1.2,但這隻 API 理論上都只有 index 這個 method,這樣是否有點浪費資源。
另外是 url 應該用 widgets/login-records 還是 widget/login-records,widget 有多隻,但實際上他們不是像 users/{user_id} 這種從多個 users data 裡面抽出某一筆的概念。
場景二:複合式動作的命名
假設要訂閱某個文章,他是拿 header 裡的 token 找出 user,然後帶入文章 id 後寫入 pivot table 那該怎麼命名。
2.1
ArticleController.php
function subscribe()
POST www.example.com/articles/{article_id}/subscription
還是應該更明確
2.2
ArticleController.php
function userSubscribe()
POST www.example.com/articles/{article_id}/user-subscription
場景三:特殊註況
以使用者密碼為例,密碼可能有重設密碼、忘記密碼
3.1
UserPasswordController.php
function reset()
users/password/reset
function forgot()
users/password/forgot
3.2
UserController.php
function resetPassword()
users/password-reset
function forgotPassword()
users/password-forgot
想請教各位會怎麼選擇。
首先,我覺得RESTful API的網址定義規則,與使用哪一種工具作為API開發工具。這兩個應該是不相關的問題。
因為使用Web API的對方,不需要知道你是使用哪一種方式進行開發。
Web API也不是只有RESTful API這一種方式而已,也有全部都用POST,再把動詞放在網址之中。
重點是,你的Web API設計邏輯,應該從頭到尾保持一致。
這樣才不會讓呼叫者感到困惑。
場景一:建立 widget
login-records、votes、stars這三組,在API使用者的直覺中,會覺得這三個也是資源
也許現在只有查詢,但是未來可能會有
新增、查詢、修改 登入資料、投票資料、星星資料
場景二:複合式動作的命名
只要網址不會混淆就可以,前端網站應該只有使用者訂閱。
除非會有提供網站的API訂閱服務,也許才需要分隔出
使用者訂閱
POST www.example.com/articles/{article_id}/user-subscription
API訂閱
POST www.example.com/articles/{article_id}/api-subscription
場景三:特殊註況
感覺密碼處理,可以放在特定使用者下,並且針對複合動作使用獨立子網址
POST /api/users/{userId}/password/reset
POST /api/users/{userId}/password/forget
PS. 按照RESTful API風格,你要不要考慮加上/api/版本號
加上/api/ 未來在做安全性設定時,可以針對/api/開頭的網址,進行統一的管理
加上版本號 以保留未來提供不相容舊版本的服務更改彈性
@run 3, 實際上,在運行API時,會有很多第三方支援工具提供良好的回應。 這給玩家帶來了很多更好的問題。 您所採取的步驟對於運行程式的過程來說很容易控制。 請分享更多.