RESTful风格API详解
在學(xué)習(xí)RESTful 風(fēng)格接口之前，即使你不知道它是什么，但你肯定會(huì)好奇它能解決什么問題？有什么應(yīng)用場景？聽完下面描述我想你就會(huì)明白：
在互聯(lián)網(wǎng)并沒有完全流行的初期，移動(dòng)端也沒有那么盛行，頁面請(qǐng)求和并發(fā)量也不高，那時(shí)候人們對(duì)接口的要求沒那么高，一些動(dòng)態(tài)頁面(jsp)就能滿足絕大多數(shù)的使用需求。
但是隨著互聯(lián)網(wǎng)和移動(dòng)設(shè)備的發(fā)展，人們對(duì)Web應(yīng)用的使用需求也增加，傳統(tǒng)的動(dòng)態(tài)頁面由于低效率而漸漸被HTML+JavaScript(Ajax)的前后端分離所取代，并且安卓、IOS、小程序等形式客戶端層出不窮，客戶端的種類出現(xiàn)多元化，而客戶端和服務(wù)端就需要接口進(jìn)行通信，但接口的規(guī)范性就又成了一個(gè)問題：
所以一套結(jié)構(gòu)清晰、符合標(biāo)準(zhǔn)、易于理解、擴(kuò)展方便讓大部分人都能夠理解接受的接口風(fēng)格就顯得越來越重要，而RESTful風(fēng)格的接口(RESTful API)剛好有以上特點(diǎn)，就逐漸被實(shí)踐應(yīng)用而變得流行起來。
現(xiàn)在，RESTful是目前最流行的接口設(shè)計(jì)規(guī)范，在很多公司有著廣泛的應(yīng)用，其中Github 的API設(shè)計(jì)就是很標(biāo)準(zhǔn)的RESTful API，你可以參考學(xué)習(xí)。
在開發(fā)實(shí)踐中我們很多人可能還是使用傳統(tǒng)API進(jìn)行請(qǐng)求交互，很多人其實(shí)并不特別了解RESTful API，對(duì)RESTful API的認(rèn)知可能會(huì)停留在：
- 面向資源類型的
- 是一種風(fēng)格
- (誤區(qū))接口傳遞參數(shù)使用斜杠(/)分割而不用問號(hào)(?)傳參。
而其實(shí)一個(gè)很大的誤區(qū)不要認(rèn)為沒有查詢字符串就是RESTful API，也不要認(rèn)為用了查詢字符串就不是RESTful API，更不要認(rèn)為用了JSON傳輸?shù)腁PI就是RESTful API。
本篇將帶你了解RESTful并用SpringBoot實(shí)戰(zhàn)RESTful API.
一、REST介紹
REST涉及一些概念性的東西可能比較多，在實(shí)戰(zhàn)RESTful API之前，要對(duì)REST相關(guān)的知識(shí)有個(gè)系統(tǒng)的認(rèn)知。
REST的誕生
REST（英文：Representational State Transfer，簡稱REST，直譯過來表現(xiàn)層狀態(tài)轉(zhuǎn)換）是一種軟件架構(gòu)風(fēng)格、設(shè)計(jì)風(fēng)格，而不是標(biāo)準(zhǔn)，只是提供了一組設(shè)計(jì)原則和約束條件。它主要用于客戶端和服務(wù)器交互類的軟件。基于這個(gè)風(fēng)格設(shè)計(jì)的軟件可以更簡潔，更有層次，更易于實(shí)現(xiàn)緩存等機(jī)制。
它首次出現(xiàn)在 2000 年 Roy Thomas Fielding 的博士論文中，這篇論文定義并詳細(xì)介紹了表述性狀態(tài)轉(zhuǎn)移（Representational State Transfer，REST）的架構(gòu)風(fēng)格，并且描述了 如何使用 REST 來指導(dǎo)現(xiàn)代 Web 架構(gòu)的設(shè)計(jì)和開發(fā)。用他自己的原話說：
我寫這篇文章的目的是：在符合架構(gòu)原理前提下，理解和評(píng)估基于網(wǎng)絡(luò)的應(yīng)用軟件的架構(gòu)設(shè)計(jì)，得到一個(gè)功能強(qiáng)、性能好、適宜通信的架構(gòu)。
需要注意的是REST并沒有一個(gè)明確的標(biāo)準(zhǔn)，而更像是一種設(shè)計(jì)的風(fēng)格，滿足這種設(shè)計(jì)風(fēng)格的程序或接口我們稱之為RESTful(從單詞字面來看就是一個(gè)形容詞)。所以RESTful API 就是滿足REST架構(gòu)風(fēng)格的接口。
Fielding博士當(dāng)時(shí)提出的是REST架構(gòu)在很久的時(shí)間內(nèi)并沒有被關(guān)注太多，而近些年REST在國內(nèi)才變得越來越流行。下面開始詳細(xì)學(xué)習(xí)REST架構(gòu)特征。
REST架構(gòu)特征
既然知道REST和RESTful的聯(lián)系和區(qū)別，現(xiàn)在就要開始好好了解RESTful的一些約束條件和規(guī)則，RESTful是一種風(fēng)格而不是標(biāo)準(zhǔn)，而這個(gè)風(fēng)格大致有以下幾個(gè)主要特征：
以資源為基礎(chǔ) ：資源可以是一個(gè)圖片、音樂、一個(gè)XML格式、HTML格式或者JSON格式等網(wǎng)絡(luò)上的一個(gè)實(shí)體，除了一些二進(jìn)制的資源外普通的文本資源更多以JSON為載體、面向用戶的一組數(shù)據(jù)(通常從數(shù)據(jù)庫中查詢而得到)。
統(tǒng)一接口: 對(duì)資源的操作包括獲取、創(chuàng)建、修改和刪除，這些操作正好對(duì)應(yīng)HTTP協(xié)議提供的GET、POST、PUT和DELETE方法。換言而知，使用RESTful風(fēng)格的接口但從接口上你可能只能定位其資源，但是無法知曉它具體進(jìn)行了什么操作，需要具體了解其發(fā)生了什么操作動(dòng)作要從其HTTP請(qǐng)求方法類型上進(jìn)行判斷。具體的HTTP方法和方法含義如下：
- GET（SELECT）：從服務(wù)器取出資源（一項(xiàng)或多項(xiàng)）。
- POST（CREATE）：在服務(wù)器新建一個(gè)資源。
- PUT（UPDATE）：在服務(wù)器更新資源（客戶端提供完整資源數(shù)據(jù)）。
- PATCH（UPDATE）：在服務(wù)器更新資源（客戶端提供需要修改的資源數(shù)據(jù)）。
- DELETE（DELETE）：從服務(wù)器刪除資源。
當(dāng)然也有很多在具體使用的時(shí)候使用PUT表示更新。從請(qǐng)求的流程來看，RESTful API和傳統(tǒng)API大致架構(gòu)如下：
URI指向資源：URI = Universal Resource Identifier 統(tǒng)一資源標(biāo)志符，用來標(biāo)識(shí)抽象或物理資源的一個(gè)緊湊字符串。URI包括URL和URN，在這里更多時(shí)候可能代指URL(統(tǒng)一資源定位符)。RESTful是面向資源的，每種資源可能由一個(gè)或多個(gè)URI對(duì)應(yīng)，但一個(gè)URI只指向一種資源。
無狀態(tài)：服務(wù)器不能保存客戶端的信息， 每一次從客戶端發(fā)送的請(qǐng)求中，要包含所有必須的狀態(tài)信息，會(huì)話信息由客戶端保存， 服務(wù)器端根據(jù)這些狀態(tài)信息來處理請(qǐng)求。當(dāng)客戶端可以切換到一個(gè)新狀態(tài)的時(shí)候發(fā)送請(qǐng)求信息， 當(dāng)一個(gè)或者多個(gè)請(qǐng)求被發(fā)送之后, 客戶端就處于一個(gè)狀態(tài)變遷過程中。每一個(gè)應(yīng)用的狀態(tài)描述可以被客戶端用來初始化下一次的狀態(tài)變遷。
REST架構(gòu)限制條件
Fielding在論文中提出REST架構(gòu)的6個(gè)限制條件，也可稱為RESTful 6大原則， 標(biāo)準(zhǔn)的REST約束應(yīng)滿足以下6個(gè)原則：
客戶端-服務(wù)端（Client-Server）: 這個(gè)更專注客戶端和服務(wù)端的分離，服務(wù)端獨(dú)立可更好服務(wù)于前端、安卓、IOS等客戶端設(shè)備。
無狀態(tài)（Stateless）：服務(wù)端不保存客戶端狀態(tài)，客戶端保存狀態(tài)信息每次請(qǐng)求攜帶狀態(tài)信息。
可緩存性（Cacheability） ：服務(wù)端需回復(fù)是否可以緩存以讓客戶端甄別是否緩存提高效率。
統(tǒng)一接口（Uniform Interface）：通過一定原則設(shè)計(jì)接口降低耦合，簡化系統(tǒng)架構(gòu)，這是RESTful設(shè)計(jì)的基本出發(fā)點(diǎn)。當(dāng)然這個(gè)內(nèi)容除了上述特點(diǎn)提到部分具體內(nèi)容比較多詳細(xì)了解可以參考這篇REST論文內(nèi)容。
分層系統(tǒng)（Layered System）：客戶端無法直接知道連接的到終端還是中間設(shè)備，分層允許你靈活的部署服務(wù)端項(xiàng)目。
按需代碼（Code-On-Demand，可選）：按需代碼允許我們靈活的發(fā)送一些看似特殊的代碼給客戶端例如JavaScript代碼。
REST架構(gòu)的一些風(fēng)格和限制條件就先介紹到這里，后面就對(duì)RESTful風(fēng)格API具體介紹。
二、RESTful API設(shè)計(jì)規(guī)范
既然了解了RESTful的一些規(guī)則和特性，那么具體該怎么去設(shè)計(jì)一個(gè)RESTful API呢？要從URL路徑、HTTP請(qǐng)求動(dòng)詞、狀態(tài)碼和返回結(jié)果等方面詳細(xì)考慮。至于其他的方面例如錯(cuò)誤處理、過濾信息等規(guī)范這里就不詳細(xì)介紹了。
URL設(shè)計(jì)規(guī)范
URL為統(tǒng)一資源定位器 ,接口屬于服務(wù)端資源，首先要通過URL這個(gè)定位到資源才能去訪問，而通常一個(gè)完整的URL組成由以下幾個(gè)部分構(gòu)成：
URI = scheme "://" host ":" port "/" path [ "?" query ][ "#" fragment ]scheme: 指底層用的協(xié)議，如http、https、ftp
host: 服務(wù)器的IP地址或者域名
port: 端口，http默認(rèn)為80端口
path: 訪問資源的路徑，就是各種web 框架中定義的route路由
query: 查詢字符串，為發(fā)送給服務(wù)器的參數(shù)，在這里更多發(fā)送數(shù)據(jù)分頁、排序等參數(shù)。
fragment: 錨點(diǎn)，定位到頁面的資源
我們在設(shè)計(jì)API時(shí)URL的path是需要認(rèn)真考慮的，而RESTful對(duì)path的設(shè)計(jì)做了一些規(guī)范，通常一個(gè)RESTful API的path組成如下：
/{version}/{resources}/{resource_id}version：API版本號(hào)，有些版本號(hào)放置在頭信息中也可以，通過控制版本號(hào)有利于應(yīng)用迭代。
resources：資源，RESTful API推薦用小寫英文單詞的復(fù)數(shù)形式。
resource_id：資源的id，訪問或操作該資源。
當(dāng)然，有時(shí)候可能資源級(jí)別較大，其下還可細(xì)分很多子資源也可以靈活設(shè)計(jì)URL的path，例如：
/{version}/{resources}/{resource_id}/{subresources}/{subresource_id}此外，有時(shí)可能增刪改查無法滿足業(yè)務(wù)要求，可以在URL末尾加上action，例如
/{version}/{resources}/{resource_id}/action其中action就是對(duì)資源的操作。
從大體樣式了解URL路徑組成之后，對(duì)于RESTful API的URL具體設(shè)計(jì)的規(guī)范如下：
HTTP動(dòng)詞
在RESTful API中，不同的HTTP請(qǐng)求方法有各自的含義，這里就展示GET,POST,PUT,DELETE幾種請(qǐng)求API的設(shè)計(jì)與含義分析。針對(duì)不同操作，具體的含義如下：
GET /collection：從服務(wù)器查詢資源的列表（數(shù)組） GET /collection/resource：從服務(wù)器查詢單個(gè)資源 POST /collection：在服務(wù)器創(chuàng)建新的資源 PUT /collection/resource：更新服務(wù)器資源 DELETE /collection/resource：從服務(wù)器刪除資源在非RESTful風(fēng)格的API中，我們通常使用GET請(qǐng)求和POST請(qǐng)求完成增刪改查以及其他操作，查詢和刪除一般使用GET方式請(qǐng)求，更新和插入一般使用POST請(qǐng)求。從請(qǐng)求方式上無法知道API具體是干嘛的，所有在URL上都會(huì)有操作的動(dòng)詞來表示API進(jìn)行的動(dòng)作，例如：query，add，update，delete等等。
而RESTful風(fēng)格的API則要求在URL上都以名詞的方式出現(xiàn)，從幾種請(qǐng)求方式上就可以看出想要進(jìn)行的操作，這點(diǎn)與非RESTful風(fēng)格的API形成鮮明對(duì)比。
在談及GET,POST,PUT,DELETE的時(shí)候，就必須提一下接口的安全性和冪等性，其中安全性是指方法不會(huì)修改資源狀態(tài)，即讀的為安全的，寫的操作為非安全的。而冪等性的意思是操作一次和操作多次的最終效果相同，客戶端重復(fù)調(diào)用也只返回同一個(gè)結(jié)果。
上述四個(gè)HTTP請(qǐng)求方法的安全性和冪等性如下：
| GET | 安全 | 冪等 | 讀操作安全，查詢一次多次結(jié)果一致 |
| POST | 非安全 | 非冪等 | 寫操作非安全，每多插入一次都會(huì)出現(xiàn)新結(jié)果 |
| PUT | 非安全 | 冪等 | 寫操作非安全，一次和多次更新結(jié)果一致 |
| DELETE | 非安全 | 冪等 | 寫操作非安全，一次和多次刪除結(jié)果一致 |
狀態(tài)碼和返回?cái)?shù)據(jù)
服務(wù)端處理完成后客戶端也可能不知道具體成功了還是失敗了，服務(wù)器響應(yīng)時(shí)，包含狀態(tài)碼和返回?cái)?shù)據(jù)兩個(gè)部分。
狀態(tài)碼
我們首先要正確使用各類狀態(tài)碼來表示該請(qǐng)求的處理執(zhí)行結(jié)果。狀態(tài)碼主要分為五大類：
1xx：相關(guān)信息
2xx：操作成功
3xx：重定向
4xx：客戶端錯(cuò)誤
5xx：服務(wù)器錯(cuò)誤
每一大類有若干小類，狀態(tài)碼的種類比較多，而主要常用狀態(tài)碼羅列在下面：
200 OK - [GET]：服務(wù)器成功返回用戶請(qǐng)求的數(shù)據(jù)，該操作是冪等的（Idempotent）。
201 CREATED - [POST/PUT/PATCH]：用戶新建或修改數(shù)據(jù)成功。
202 Accepted - [*]：表示一個(gè)請(qǐng)求已經(jīng)進(jìn)入后臺(tái)排隊(duì)（異步任務(wù)）
204 NO CONTENT - [DELETE]：用戶刪除數(shù)據(jù)成功。
400 INVALID REQUEST - [POST/PUT/PATCH]：用戶發(fā)出的請(qǐng)求有錯(cuò)誤，服務(wù)器沒有進(jìn)行新建或修改數(shù)據(jù)的操作，該操作是冪等的。
401 Unauthorized - [*]：表示用戶沒有權(quán)限（令牌、用戶名、密碼錯(cuò)誤）。
403 Forbidden - [*]:表示用戶得到授權(quán)（與401錯(cuò)誤相對(duì)），但是訪問是被禁止的。
404 NOT FOUND - [*]：用戶發(fā)出的請(qǐng)求針對(duì)的是不存在的記錄，服務(wù)器沒有進(jìn)行操作，該操作是冪等的。
406 Not Acceptable - [GET]：用戶請(qǐng)求的格式不可得（比如用戶請(qǐng)求JSON格式，但是只有XML格式）。
410 Gone -[GET]：用戶請(qǐng)求的資源被永久刪除，且不會(huì)再得到的。
422 Unprocesable entity - [POST/PUT/PATCH] 當(dāng)創(chuàng)建一個(gè)對(duì)象時(shí)，發(fā)生一個(gè)驗(yàn)證錯(cuò)誤。
500 INTERNAL SERVER ERROR - [*]：服務(wù)器發(fā)生錯(cuò)誤，用戶將無法判斷發(fā)出的請(qǐng)求是否成功。
返回結(jié)果
針對(duì)不同操作，服務(wù)器向用戶返回?cái)?shù)據(jù)，而各個(gè)團(tuán)隊(duì)或公司封裝的返回實(shí)體類也不同，但都返回JSON格式數(shù)據(jù)給客戶端。
三、一個(gè)RESTful API案例
上面講了RESTful理論知識(shí)，下面動(dòng)手實(shí)現(xiàn)一個(gè)小案例吧！
預(yù)備
在本案例的實(shí)戰(zhàn)中，我們訪問的RESTful接口都是對(duì)數(shù)據(jù)庫真實(shí)的操作，新建數(shù)據(jù)庫，創(chuàng)建一個(gè)數(shù)據(jù)庫和表(根據(jù)自己喜好)。
選擇Maven依賴的時(shí)候，只需要勾選其中Spring的Web模塊、MySQL驅(qū)動(dòng)以及MyBatis框架。
本案例的POJO創(chuàng)建Dog.java實(shí)體對(duì)象，其具體構(gòu)造為：
package com.restfuldemo.pojo;public class Dog {private int id;//唯一id標(biāo)識(shí)private String name;//名稱private int age;//年齡//省略get set }上面創(chuàng)建好了項(xiàng)目，我們就開始構(gòu)建RESTful風(fēng)格的API。在具體構(gòu)建RESTful API的時(shí)候，需要對(duì)各種請(qǐng)求有更細(xì)致的認(rèn)知，當(dāng)然，本案例在實(shí)現(xiàn)各種請(qǐng)求的時(shí)候?yàn)榱搜菔镜谋憬莶]有完全遵循RESTful API規(guī)范，例如版本號(hào)等信息這里就不添加了，案例更側(cè)重于使用SpringBoot實(shí)現(xiàn)這個(gè)接口。
本案例實(shí)現(xiàn)對(duì)dog資源的增刪改查，如下是非RESTful 和RESTful接口對(duì)比：
| 獲取dog | /dogs/query/{dogid} | GET： /dogs/{dogid} |
| 插入dog | /dogs/add | POST： /dogs |
| 更新dog | /dogs/update/{dogid} | PUT：/dogs/{dogid} |
| 刪除dog | /dods/delete/{dogid} | DELETE：/dogs/{dogid} |
另外在使用postman進(jìn)行發(fā)送請(qǐng)求的時(shí)候，有三種常用的文件類型傳遞到后端：
form-data ：就是form表單中的multipart/form-data，會(huì)將表單數(shù)據(jù)處理為一條信息，用特定標(biāo)簽符將一條條信息分割開，而這個(gè)文件類型通常用來上傳二進(jìn)制文件。
x-www-form-urlencoded：就是application/x-www-form-urlencoded，是form表單默認(rèn)的encType，form表單會(huì)將表單內(nèi)的數(shù)據(jù)轉(zhuǎn)換為鍵值對(duì)，這種格式不能上傳文件。
raw：可以上傳任意格式的文本，可以上傳Text，JSON，XML等，但目前大部分還是上傳JSON格式數(shù)據(jù)。當(dāng)后端需要接收J(rèn)SON格式數(shù)據(jù)處理的時(shí)候，可以采用這種格式來測試。
因?yàn)镚ET請(qǐng)求查詢參數(shù)在URL上，其他類型請(qǐng)求使用x-www-form-urlencoded方式向后端傳值。
GET POST PUT DELETE請(qǐng)求
GET請(qǐng)求用來獲取資源：GET請(qǐng)求會(huì)向數(shù)據(jù)庫發(fā)索取數(shù)據(jù)的請(qǐng)求，從而來獲取資源，該請(qǐng)求就像數(shù)據(jù)庫的select操作一樣，只是用來查詢數(shù)據(jù)，不會(huì)影響資源的內(nèi)容。無論進(jìn)行多少次操作，結(jié)果都是一樣的。
并且GET請(qǐng)求會(huì)把請(qǐng)求的參數(shù)附加在URL后面，但是不同的瀏覽器對(duì)其有不同的大小長度限制。
在本案例中，我們設(shè)計(jì)兩個(gè)GET請(qǐng)求的API。
GET /dogs ：用來返回dog資源的列表。
GET /dogs/{dogid} ：用來查詢此id的單個(gè)dog資源。
POST請(qǐng)求用來新增一個(gè)資源 : POST請(qǐng)求向服務(wù)器發(fā)送數(shù)據(jù)，但是該請(qǐng)求會(huì)改變數(shù)據(jù)的內(nèi)容(新添)，就像數(shù)據(jù)庫的insert操作一樣，會(huì)創(chuàng)建新的內(nèi)容。且POST請(qǐng)求的請(qǐng)求參數(shù)都是請(qǐng)求體中，其大小是沒有限制的。
在本案例中，我們設(shè)計(jì)以下POST請(qǐng)求的API。
POST /dogs ：服務(wù)端新增一個(gè)dog資源。
PUT請(qǐng)求用來更新資源，PUT請(qǐng)求是向服務(wù)器端發(fā)送數(shù)據(jù)的， 與POST請(qǐng)求不同的是，PUT請(qǐng)求側(cè)重于數(shù)據(jù)的修改 ,就像數(shù)據(jù)庫中update一樣，而POST請(qǐng)求側(cè)重于數(shù)據(jù)的增加。
在本案例中，我們設(shè)計(jì)以下POST請(qǐng)求的API。
PUT /dogs/{dogid} ：用來更新此id的單個(gè)dog資源。
DELETE 請(qǐng)求用來刪除資源，DELETE請(qǐng)求用途和它字面意思一致，用來刪除資源。和數(shù)據(jù)庫中delete相對(duì)應(yīng)。
在本案例中，我們設(shè)計(jì)以下DELETE請(qǐng)求的API。
DELETE /dogs/{dogid} ：用來刪除此id的單個(gè)dog資源。
對(duì)應(yīng)的Mapper文件為：
package com.restfuldemo.mapper;import com.restfuldemo.pojo.Dog; import org.apache.ibatis.annotations.*; import java.util.List;@Mapper public interface DogMapper {@Select("select * from dog")List<Dog> getAllDog();@Select("select * from dog where id=#{id}")Dog getDogById(@Param("id") int id);@Insert("insert into dog (name,age) values (#{name},#{age})")boolean addDog(Dog dog);@Update("update dog set name=#{name},age=#{age} where id=#{id}")boolean updateDog(Dog dog);@Delete("delete from dog where id=#{id}")boolean deleteDogById(int id); }對(duì)應(yīng)controller文件為：
package com.restfuldemo.controller;import com.restfuldemo.mapper.DogMapper; import com.restfuldemo.pojo.Dog; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.*;import java.util.Arrays; import java.util.List;@RestController public class TestController {@Autowired(required = false)DogMapper dogMapper;@GetMapping("dogs")public List<Dog> getDogs(){return dogMapper.getAllDog();}@GetMapping("dogs/{id}")public Dog getDogById(@PathVariable("id") int id){Dog dog=dogMapper.getDogById(id);return dog;}@PostMapping("dogs")public boolean addDog(Dog dog){return dogMapper.addDog(dog);}@PutMapping("dogs/{id}")public boolean updateDog(@PathVariable("id")int id,@RequestParam("name")String name,@RequestParam("age")int age){Dog dog=dogMapper.getDogById(id);dog.setName(name);dog.setAge(age);return dogMapper.updateDog(dog);}@DeleteMapping("dogs/{id}")public boolean deleteDog(@PathVariable("id") int id){return dogMapper.deleteDogById(id);} }經(jīng)過筆者測試一切都是ok的，如果要項(xiàng)目源文件請(qǐng)聯(lián)系筆者發(fā)你哈！
總結(jié)
RESTful風(fēng)格的API 固然很好很規(guī)范，但大多數(shù)互聯(lián)網(wǎng)公司并沒有按照或者完全按照其規(guī)則來設(shè)計(jì)，因?yàn)镽EST是一種風(fēng)格，而不是一種約束或規(guī)則，過于理想的RESTful API 會(huì)付出太多的成本。
比如RESTful API也有一些缺點(diǎn)
- 比如操作方式繁瑣，RESTful API通常根據(jù)GET、POST、PUT、DELETE 來區(qū)分操作資源的動(dòng)作，而HTTP Method 本身不可直接見，是隱藏的，而如果將動(dòng)作放到URL的path上反而清晰可見，更利于團(tuán)隊(duì)的理解和交流。
- 并且有些瀏覽器對(duì)GET,POST之外的請(qǐng)求支持不太友好，還需要特殊額外的處理。
- 過分強(qiáng)調(diào)資源，而實(shí)際業(yè)務(wù)API可能有各種需求比較復(fù)雜，單單使用資源的增刪改查可能并不能有效滿足使用需求，強(qiáng)行使用RESTful風(fēng)格API只會(huì)增加開發(fā)難度和成本。
所以，當(dāng)你或你們的技術(shù)團(tuán)隊(duì)在設(shè)計(jì)API的時(shí)候，如果使用場景和REST風(fēng)格很匹配，那么你們可以采用RESTful 風(fēng)格API。但是如果業(yè)務(wù)需求和RESTful風(fēng)格API不太匹配或者很麻煩，那也可以不用RESTful風(fēng)格API或者可以借鑒一下，畢竟無論那種風(fēng)格的API都是為了方便團(tuán)隊(duì)開發(fā)、協(xié)商以及管理，不能墨守成規(guī)。
到這里RESTful API的介紹和實(shí)戰(zhàn)就結(jié)束啦，本篇首先從RESTful的一些特點(diǎn)進(jìn)行介紹，再到SpringBoot實(shí)戰(zhàn)RESTful API，最后也說了一些RESTful API并不完美的地方，相信睿智的你對(duì)RESTful 一定有了很深刻的理解。在以后項(xiàng)目的API設(shè)計(jì)上定能有所優(yōu)化。
不同的人對(duì)RESTful API可能有著不同的理解，但存在即合理，RESTful API有著其鮮明的優(yōu)勢和特點(diǎn)，目前也是一種API設(shè)計(jì)的主要選型之一，所以掌握和理解RESTful API還是相當(dāng)重要的!
總結(jié)
以上是生活随笔為你收集整理的RESTful风格API详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Lecture 13: Bernoull
- 下一篇： EC20使用之 quectel-CM的启