之前有在讀一些API相關的書，知道所謂的dx(developer experience)
如果API的設計有時候過於偏重後端、沒有針對前端需求優化
蠻容易使得這個dx下降、低落。
或許有時候case by case,舉例來說有些api可能比較偏重產品內部使用...並沒有到那種Api as service的程度...或許對於dx的要求沒那麼高，因為也都是產品內部的developer接...（是嗎？
有些人認為設計應該反映所謂的「真實世界」，因此主張該傳的就傳、不要為UI設計API...
我有部分同意是這樣，尤其可能前端畫面/UX 更是如此
但就很好奇，在後端api的implement和design中也是有必要反應這樣的「真實世界」嗎？有些商業邏輯隱藏起來讓前端容易接不好嗎？
或許這個問題之前在Ptt就有吵過？API格式應該由前端開，還是後端開？
不知道有關這一塊的best practice是什麼？到底是要傳一堆可能現在UI沒用到但未來“可能”用到的欄位？還是要按照UI的部分一步一步一階段一階段的處理（但這樣API的進度被UI/UX所影響，也會造成設計組的壓力吧？）
想要知道各位大大們的看法？
已邀請的邦友 {{ invite_list.length }}/5
你這邊說的後端API應該是指給UI使用的API,但先提醒下這種API不是後端,嚴格說起來還是前端.
以定義來說這種API的目的是為了前端UI設計,所以設計理念上是以前端UI需求為出發點,前端要什麼就給什麼,而非通用設計.
當然這樣做對於查詢需求設計上就會過於繁瑣,早期為了解決此問題,有出個OData協議,但OData的安全性太低,操作權完全在前端,因此目前很多大廠開始採用有限制的GraphQL協議解決此問題,有興趣可以研究下,但GraphQL只是協議,最終整合到SQL等相關的Library並不多,在.net與java等正規語言還可以找到相對應的library,但其他語言可能沒有,然而要自己實現這個工程浩大.
不用想太多。就分兩種一個給 frontend，一個給 backend。
你的路徑可以明確說明用途
例如用戶的訂單詳細頁。就給前端 UI 會用到的東西。
[GET] frontend/order/[user_id]
[POST] backend/order 就後端建立訂單
backend 主要用途為資料交換為主。
當然可以命名更藝術一點。
RESTFul 只是風格，非強制。
「有些人認為設計應該反映所謂的「真實世界」，因此主張該傳的就傳、不要為UI設計API...」
與其說「反應真實世界」，不如說設計開發 API 的時候，要設計的有彈性一點而不是被單一 UI 功能限制綁死（API 的進度也不會被 UI/UX 所影響），也就是內文提到的「這個功能該傳什麼就傳什麼」。
總之，隕石砸下來的時候你就會感謝當初的自己把 API 設計的夠彈性
如同 raytracy 大大所說，後端可以開出 GraphQL 的 API，讓前端自行定義想要抓到什麼欄位與資料，對於相互關聯的資料也不用呼叫多個 api 來組資料，可以一次藉由 GraphQL 回傳想要的資料內容與格式
iThome鐵人賽
看影片追技術