第七色在线视频,2021少妇久久久久久久久久,亚洲欧洲精品成人久久av18,亚洲国产精品特色大片观看完整版,孙宇晨将参加特朗普的晚宴

資源路徑（URI）

用戶表

ID、用戶名、密碼、注冊時間

文章表

文章 ID、標題、內(nèi)容、發(fā)表時間、用戶 ID

確認設計要素

• 資源路徑：/users、/articles

• HTTP 動詞：GET、POST、DELETE、PUT

• 過濾信息：文章的分頁篩選

• 狀態(tài)碼：200、404、422、403

• 錯誤處理：輸出 JSON 格式錯誤信息

• 返回結果：輸出 JSON 數(shù)組或 JSON 對象

項目需求

• 用戶登錄、注冊

• 文章發(fā)表、編輯、管理、列表

返回結果

針對不同操作，服務器向用戶返回的結果應該符合以下規(guī)范：

• GET /collections：返回資源對象的列表（數(shù)組）

• GET /collections/identity：返回單個資源對象

• POST /collections：返回新生成的資源對象

• PUT /collections/identity：返回完整的資源對象

• PATCH /collections/identity：返回被修改的屬性

• DELETE /collections/identity：返回一個空文檔
  

錯誤處理

如果狀態(tài)碼是 4xx 或者 5xx，就應該向用戶返回出錯信息。一般來說，返回的信息中將 error 作為鍵名，出錯信息作為鍵值即可

{
????“error'”:?“參數(shù)錯誤”
}

狀態(tài)碼

服務器向用戶返回的狀態(tài)碼和提示信息，使用標準 HTTP 狀態(tài)碼。

• 200 OK 服務器成功返回用戶請求的數(shù)據(jù)，該操作是冪等的。

• 201 CREATED 新建或修改數(shù)據(jù)成功。

• 204 NO CONTENT 刪除數(shù)據(jù)成功。

• 400 BAD REQUEST 用戶發(fā)出的請求有錯誤，該操作是冪等的。

• 401 Unauthorized 表示用戶沒有認證，無法進行當前操作。

• 403 Forbidden 表示用戶訪問是被禁止的。

• 422 Unprocesable Entity 當創(chuàng)建一個對象時，發(fā)生一個驗證錯誤。

• 500 INTERNAL SERVER ERROR 服務器發(fā)生錯誤，用戶將無法判斷發(fā)出的請求是否成功。

過濾信息

如果記錄數(shù)量很多，服務器不可能都將它們返回給用戶。API 應該提供參數(shù)，過濾返回結果。

舉例

• ?offset=10：指定返回記錄的開始位置。

• ?page=2&per_page=100：指定第幾頁，以及每頁的記錄數(shù)。

• ?sortby=name&order=asc：指定返回結果排序，以及排序順序。
  

• ?animal_type_id=1：指定篩選條件

HTTP 動詞

對于資源的操作（CURD），由 HTTP 動詞（謂詞）表示。

• GET：從服務器取出資源（一項或多項）。

• POST：在服務器新建一個資源。

• PUT：在服務器更新資源（客戶端提供改變后的完整資源）

• PATCH：在服務器更新資源（客戶端提供改變的屬性）。

• DELETE：從服務器刪除資源。

舉例

• POST /zoos：新建一個動物園

• GET /zoos/ID：獲取某個指定動物園的信息

• PUT /zoos/ID：更新某個指定動物園的信息

• DELETE /zoos/ID：刪除某個動物園

資源路徑

在 RESTful 架構中，每個網(wǎng)址代表一種資源，所以網(wǎng)址中不能有動詞，只能有名詞。一般來說 API 中的名詞應該使用復數(shù)。

舉例

舉例來說，有一個 API 提供動物園（zoo）的信息，還包括各種動物和雇員的信息，則它的路徑應該設計成下面這樣。

https://api.example.com/v1/zoos //動物園資源

https://api.example.com/v1/animals //動物資源

https://api.example.com/v1/employees?//雇員資源

如何設計 RESTful API

• 資源路徑（URI）

• HTTP 動詞

• 過濾信息

• 狀態(tài)碼

• 錯誤處理

• 返回結果
  

安全性

RESTful 對于資源型服務接口來說很合適，同時特別適合對于效率要求很高，但是對于安全要求不高的場景。

SOAP 的成熟性可以給需要提供給多開發(fā)語言的，對于安全性要求較高的接口設計帶來便利。所以我覺得純粹說什么設計模式將會占據(jù)主導地位沒有什么意義，關鍵還是看應用場景。

效率和易用性

SOAP 由于各種需求不斷擴充其本身協(xié)議的內(nèi)容，導致在 SOAP 處理方面的性能有所下降。同時在易用性方面以及學習成本上也有所

增加。

RESTful 由于其面向資源接口設計以及操作抽象簡化了開發(fā)者的不良設計，同時也最大限度的利用了 Http 最初的應用協(xié)議設計理念。

SOAP WebService

WebService 是一種跨編程語言和跨操作系統(tǒng)平臺的遠程調(diào)用技術。

WebService 通過 HTTP 協(xié)議發(fā)送請求和接收結果時采用 XML 格式封裝，并增加了一些特定的 HTTP 消息頭，這些特定的 HTTP 消息頭和 XML 內(nèi)容格式就是 SOAP 協(xié)議。

HTTP 協(xié)議 - 響應

• 組成格式：狀態(tài)行、消息報頭、響應正文

• 狀態(tài)行

  HTTP-Version Status-Code Reason-Phrase CRLF

  HTTP/1.1 200 OK

• 常用狀態(tài)碼
  

  200 OK //客戶端請求成功
  

  400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解

  401 Unauthorized //服務器收到請求，但是拒絕提供服務

  404 Not Found //請求資源不存在

  500 Internal Server Error //服務器發(fā)生不可預期的錯誤

  503 Server Unavailable //服務器當前不能處理客戶端的請求

HTTP 協(xié)議 - 請求

• 組成格式：請求行、消息報頭、請求正文

• 請求行

  格式如下：Method Request - URI HTTP - Version CRLF

• 舉例

  GET HTTP/1.1 CRLF

• 請求方法
  

  GET 請求獲取 Request-URI 所標識的資源

  POST 在 Request-URI 所標識的資源后附加新的數(shù)據(jù)

  HEAD 請求獲取由 Request-URI 所標識的資源的響應消息報頭
  

  PUT 請求服務器存儲一個資源，并用 Request-URI 作為其標識
  

  DELETE 請求服務器刪除 Request-URI 所標識的資源

  OPTIONS 請求查詢服務器的性能，或者查詢與資源相關的選項和需求

HTTP 協(xié)議 - URL

• HTTP 是一個屬于應用層的協(xié)議，特點是簡捷、快速。

• schema://host[:port]/path[?query-string][#anchor]

  • scheme：指定低層使用的協(xié)議（例如：http, https, ftp）

  • host：服務器的 IP 地址或者域名

  • port：服務器端口，默認為 80

  • path：訪問資源的路徑

  • query-string：發(fā)送給 http 服務器的數(shù)據(jù)

  • anchor：錨
    

資源

什么是資源？

所謂“資源”，就是網(wǎng)絡上的一個實體，或者說是網(wǎng)絡上的一個具體信息。

設計概念和準則

• 網(wǎng)絡上的所有事物都可以被抽象為資源。

• 每一個資源都有唯一的資源標識，對資源的操作不會改變這些標識。

• 所有的操作都是無狀態(tài)的。

RESTful 是什么

本質(zhì)：一種軟件架構風格

核心：面向資源

解決的問題

• 降低開發(fā)的復雜性

• 提高系統(tǒng)的可伸縮性

如何設計RESTful API

設計資源路徑：網(wǎng)址代表一種資源，網(wǎng)址中不能出現(xiàn)動詞，只能有名詞，一般來說名詞應該使用復數(shù)。

設計RESTFul API 六要素

RESTful面向資源設計API， 一種軟件架構風格

soap WebService接口

常用狀態(tài)碼