討論

2021/7/28

背景知識

• REST 是什麼？ 資料傳輸規則

• REST level 2, 3

• 為什麼要用？ 減少溝通成本

• 使用 API 會遇到什麼困難？要注意什麼？

• 怎樣是安全的？

• RFC 是什麼？ 白皮書、字典

討論

200+massage 是邪教？status code討論

• GraphQL 是邪教？ 這個 spec 不好嗎？

• 為什麼REST一定要status code

• REST / Graph 的本質

• REST操作資源？

• 可以兩個都用嗎

為什麼REST要status code這樣做？

• REST對單一資源操作 endpoint 可以用 status code 表示對資源操作的結果 code = resource status

• QL 一次 query 很多資源，404沒辦法判斷是找不到哪一層 code = http server status 404 schema 不存在

ql 可以設定要不要部份 error

遵守REST的status code會有什麼困擾？

• 想讀一篇文章有 bug (data 有問題)但不是400, 500 總之就是 RFC 沒有定義到的錯誤

• 這樣就只能船 200 + message

• 或是只能自訂錯誤帶碼像是 4001 4002

• status code 的主詞

Etag

• 一致性判斷

• kk 覺得適合用在共筆可以 lock 正在編輯的部分race condition 離線編輯是否用這個做的

主動推播給client 資源變動

hook change something, call something

broker Kafka, RabbitMQ

冪等性

DELETE 的資源不存在要回 200 ? 204 ?

兩個情境：

• DELETE不存在的資源 200? 204?

• DELETE 成功 200? 204?

刪第一次 204 第二次200 這樣有冪等嗎？

冪等性是對資料？還是伺服器的行為？

status 的主詞是 resource 才回答 404而且是對原本的資源

• 都回 204：都是刪除後的結果

• 都兩百：刪除的行為成功所以是200，但在刪除的時候變成是用行為作為status主詞？

希望冪等性也要有一置性

https://datatracker.ietf.org/doc/html/rfc2616

9.7 DELETE The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is giv----

A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.

驗證

前端的驗證主要是防呆，節省後端資源與增加使用者體驗 後端無論如何都要做

Cache Control

Etag, last modified

$time = Storage::lastModified('file1.jpg');

useSWR

Metrics

怎麼看效能問題、測performance？回傳速度？渲染速度？

performance metrics profiling

後端：

profiling 測試後端 API 效能

API profiling tool 推薦

• 壓力測試工具可以測出後端 response time 時間

• 可以用 postman 寫腳本做

• loadtest(npm套件)有點歷史

• ApacheBench ( ab ) (cli tool) 使用ApacheBench 進行網站的壓力測試| The Will Will Web

前端：

• bundle size reduce

• react/vue profiling tool

• slow render 可以錄製每一個render，re render 還，要避免載入過大

• 使用 React Profiler 來觀察 React Web App 的渲染狀況並進行效能優化

Chrome

• chrome performance 錄影會跑一次所有渲染機置(難)

安全

private api/public api

• private 除了不要公開，一般會鎖 IP

看到別人的訂單

XSS

拒絕式攻擊 = DDoS

從屬關係

/users/u001/orders/
/orders?userId=u001

如果選二，是不是不會有兩層的狀況

第二種，沒有強綁定，隱私

可以從安全或scope選擇

分層，好分權限，第二層可以重複

rate limite 一定要做

upstash.io https://upstash.com/

CSP 避免瀏覽器亂做事

status : resource / action / server
冪等/ 一致

resource => 403
action => 404
要考慮其它API是用什麼邏輯，要一致性

errors 200 也放是一致性，

kk 建議status 用在 UI狀態歸類(改叫type)

message => for dev ( 做多國與 mapping )/ for user ?

也沒有明確需求要 group 其實就不要加，over engineering ㄌ

errors 通常用 list 因為是 s

給 user 錯誤訊息要放前端還是後端？

• 放codebase要一直要後端改很麻煩，Jo覺得給error code比較好，前端比較好修改/多國語

• 有些網站做地方語系會有error admin讓客服修改錯誤訊息

strict-transport-security

TLS

preflight

RFC

還有定義關鍵字 https://datatracker.ietf.org/doc/html/draft-bradner-key-words-02

REST讓你知道自己在控制哪個資源

hypermedia 再也不用看doc，打了第一隻api就知道接下來有哪些連帶資源

REST+ yaml 可以產出整個文件

401 應該是 Unauthentication 我不認識你，但改不動了

403 是Unauthoriaed 你沒有權限

控制參數

業界玫在管 REST

只有大公司像google 在會盡量去遵守，像是 login api 用 /user?action=login