使用NestJS和Prisma構建REST API：身份驗證
應該：
{
userName: "Mohammad Faisal"
userId: "1"
}RESTful HTTP服務必須實現/health和/version和/metricsAPI端點。他們將提供以下信息。
/health
用200 OK狀態碼響應對/health的請求。
/version
用版本號響應對/version的請求。
/metrics
這個端點將提供各種指標，如平均響應時間。
也強烈推薦使用/debug和/status端點。
不要只使用表名作為資源名。從長遠來看，這種懶惰是有害的。
不應該：
product_order應該：
product-orders這是因為公開底層體系結構不是你的目的。
有許多好的API設計工具用于編寫好的文檔，例如：
擁有良好而詳細的文檔可以為API使用者帶來良好的用戶體驗。
始終對API使用版本控制，并將其向左移動，使其具有最大的作用域。版本號應該是v1，v2等等。
應該：http://api.domain.com/v1/shops/3/products
始終在API中使用版本控制，因為如果API被外部實體使用，更改端點可能會破壞它們的功能。
如果API返回一個對象列表，則響應中總是包含資源的總數。你可以為此使用total屬性。
不應該：
{
users: [
...
]
}應該：
{
users: [
...
],
total: 34
}在GET操作中始終接受limit和offset參數。
應該：
GET /shops?offset=5&limit=5這是因為它對于前端的分頁是必要的。
返回的數據量也應該考慮在內。添加一個fields參數，只公開API中必需的字段。
例子：
只返回商店的名稱，地址和聯系方式。
GET /shops?fields=id,name,address,contact在某些情況下，它還有助于減少響應大小。
這是一種非常糟糕的做法，因為url經常被記錄，而身份驗證令牌也會被不必要地記錄。
不應該：
GET /shops/123?token=some_kind_of_authenticaiton_token相反，通過頭部傳遞它們：
Authorization: Bearer xxxxxx, Extra yyyyy此外，授權令牌應該是短暫有效期的。
服務器不應該假定內容類型。例如，如果你接受application/x-www-form-urlencoded，那么攻擊者可以創建一個表單并觸發一個簡單的POST請求。
因此，始終驗證內容類型，如果你想使用默認的內容類型，請使用：
content-type: application/jsonHTTP方法用于解釋CRUD功能。
GET：檢索資源的表示形式。
POST：創建新的資源和子資源。
PUT：更新現有資源。
PATCH：更新現有資源，它只更新提供的字段，而不更新其他字段。
DELETE：刪除已存在的資源。
以下是一些實際例子：
一定要為所有面向公共的API支持CORS（跨源資源共享）頭部。
考慮支持CORS允許的“*”來源，并通過有效的OAuth令牌強制授權。
避免將用戶憑證與原始驗證相結合。
在所有端點、資源和服務上實施HTTPS（tls加密）。
強制并要求所有回調url、推送通知端點和webhooks使用HTTPS。
當客戶端向服務發出無效或不正確的請求，或向服務傳遞無效或不正確的數據，而服務拒絕該請求時，就會出現錯誤，或者更具體地說，出現服務錯誤。
例子包括無效的身份驗證憑證、不正確的參數、未知的版本id等。
如果您對API格式的決定有疑問，這些黃金規則可以幫助我們做出正確的決定。
就是這樣——如果你已經走到了這一步，恭喜你！希望你學到了一些東西。
希望你度過美好的一天！
文章轉自微信公眾號@芋道源碼
