※ 本文為 terievv 轉寄自 ptt.cc 更新時間: 2019-03-14 01:23:19
看板 Soft_Job
作者 標題 Re: [請益] 所以,到底什麼是RESTful API?
時間 Tue Mar 12 15:56:24 2019
沒想到RESTful吸引這麼多人討論
看來RESTful真的是一個概念各種表述
小弟剛接觸RESTful的時候
曾經很熱血的把一百多支API從只有post/get改成RESTful
改完之後有些人覺得好 有些人覺得無所謂
也有人覺得一律POST 這樣client實作最方便 只要能用就好
後來我遇到一個例子
要提供API搜尋文章歷史紀錄 可選的輸入欄位有N種
url可能長這樣
ooxx.com/posts/query?writerNameKeyword=..&minRate=..&maxRate=..
假設還有瀏覽數/發文日期/國家雜七雜八的可選輸入欄位
因為是可選所以也不適合用posts/{country}/query?
日期 瀏覽數這類的欄位看起來也是放在querystring比較好
最後整個url就超級長
雖然SPA設計不會讓這串url出現在瀏覽器網址
但是看到這串這麼長還是會覺得很怪
這時候就很想用POST把參數都放body 小組討論後也覺得這樣比較好
各位覺得呢?
後來其他系統我也不再堅持query一定要用GET了
順帶一提 最近發現蝦皮購物前端呼叫的api也改成不是restful了..
v2版本的下架商品是PUT , 把整個商品資料json帶入 status改成8
刪除商品是 DELETE products/{id}
v2版本的下架商品是PUT , 把整個商品資料json帶入 status改成8
刪除商品是 DELETE products/{id}
v3版本entry變成 update_product 跟 delete_product
verb都是POST
以前在開發也經常為了RESTful命名花很多時間
甚至還要跟小組討論 或是有人寫出不是RESTful的時候還要重寫
最後APP開發者串接還是要看文件才行
只是看到RESTful的接口可能覺得很乾淨 用起來有一種爽度
但是文件不說明你還是不會知道這支API所有的細節
反應到開發成本上 堅持完全RESTful的設計 我是沒有感覺到優勢
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.137.82.149
※ 文章代碼(AID): #1SXsOhpy (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1552377387.A.CFC.html
※ 同主題文章:
03-11 21:26 ■ Re: [請益] 所以,到底什麼是RESTful API?
03-12 14:14 ■ Re: [請益] 所以,到底什麼是RESTful API?
● 03-12 15:56 ■ Re: [請益] 所以,到底什麼是RESTful API?
→ : 每個人都要有概念，Restful才有優勢，不然光是理解就1F 03/12 16:22
→ : 花更多時間了
→ : 花更多時間了
→ : 學習過程中我對restful最大誤解是要拋棄querystring3F 03/12 16:29
→ : 但實際上沒有要求拋棄的樣子 忘了從哪傳來的
→ : 但實際上沒有要求拋棄的樣子 忘了從哪傳來的
推 : 因為沒 querystring 最漂亮吧，其實這些問題也是現在5F 03/12 17:32
→ : GraphQL 的由來
→ : GraphQL 的由來
→ : 查到有要符合HATEOAS 才可以叫RESTful?7F 03/12 19:10
推 : query string用在optional parameters 但是還是解決不了8F 03/12 20:21
→ : 欄位大量排列組合的問題 所以才需要GraphQL
→ : 欄位大量排列組合的問題 所以才需要GraphQL
→ : 初學者都會認為直接POST最快最穩 但是有一些隱性的問題跟劣勢10F 03/12 21:28
→ : 寫久還是把Http Method跟Code搬出來比較嚴謹
→ : 寫久還是把Http Method跟Code搬出來比較嚴謹
推 : 我也有這問題 查詢條件多的時候大家都怎麼弄12F 03/13 13:43
--
※ 看板: terievv 文章推薦值: 0 目前人氣: 0 累積人氣: 161
回列表(←)
分享