iT邦幫忙

0

到底API 設計的方向該往哪裡去?

之前有在讀一些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所影響,也會造成設計組的壓力吧?)

想要知道各位大大們的看法?

圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中
10
Ray
iT邦大神 1 級 ‧ 2021-11-13 23:58:31
最佳解答

如果你的困擾是:現在沒用到但未來可能用到的欄位,
GraphQL 可以讓前端只收到他想查詢的 Key:Value,
不需要把一大堆沒用的未來欄位全部都吐出來給他:

3
programlin
iT邦新手 5 級 ‧ 2021-11-14 10:02:27

你這邊說的後端API應該是指給UI使用的API,但先提醒下這種API不是後端,嚴格說起來還是前端.
以定義來說這種API的目的是為了前端UI設計,所以設計理念上是以前端UI需求為出發點,前端要什麼就給什麼,而非通用設計.
當然這樣做對於查詢需求設計上就會過於繁瑣,早期為了解決此問題,有出個OData協議,但OData的安全性太低,操作權完全在前端,因此目前很多大廠開始採用有限制的GraphQL協議解決此問題,有興趣可以研究下,但GraphQL只是協議,最終整合到SQL等相關的Library並不多,在.net與java等正規語言還可以找到相對應的library,但其他語言可能沒有,然而要自己實現這個工程浩大.

r567tw iT邦研究生 5 級 ‧ 2021-11-14 23:04:28 檢舉

還蠻好奇你說的OData協議,有沒有更多的相關資訊可以看看呢?

2
Terry L.
iT邦研究生 4 級 ‧ 2021-11-15 13:15:45

不用想太多。就分兩種一個給 frontend,一個給 backend。

你的路徑可以明確說明用途

例如用戶的訂單詳細頁。就給前端 UI 會用到的東西。
[GET] frontend/order/[user_id]

[POST] backend/order 就後端建立訂單
backend 主要用途為資料交換為主。

當然可以命名更藝術一點。
RESTFul 只是風格,非強制。

2
GreedIsGood
iT邦新手 4 級 ‧ 2021-11-15 13:18:04

「有些人認為設計應該反映所謂的「真實世界」,因此主張該傳的就傳、不要為UI設計API...」
與其說「反應真實世界」,不如說設計開發 API 的時候,要設計的有彈性一點而不是被單一 UI 功能限制綁死(API 的進度也不會被 UI/UX 所影響),也就是內文提到的「這個功能該傳什麼就傳什麼」。

總之,隕石砸下來的時候你就會感謝當初的自己把 API 設計的夠彈性/images/emoticon/emoticon01.gif

3
阿翔
iT邦新手 4 級 ‧ 2021-11-15 14:43:10

如同 raytracy 大大所說,後端可以開出 GraphQL 的 API,讓前端自行定義想要抓到什麼欄位與資料,對於相互關聯的資料也不用呼叫多個 api 來組資料,可以一次藉由 GraphQL 回傳想要的資料內容與格式

我要發表回答

立即登入回答