对“RESTful”的理解

大二的时候接触过RESTful这个概念，也试着写过RESTful API，但是到现在也没有完全理解过这个概念，最近耳边又出现了这个词，于是就开始去再次了解了一下

1.传统API接口

如果说你要删除一个数据，以往的做法通常是 delete/{id}　
如果你要更新一个数据，可能是Post数据放Body，然后方法是 update/{id}，或者artichle/{id}?method=update

缺点

状态混乱：有状态和无状态全部混在一起
无序：返回错误信息较随意
URL地址混乱

2.REST

了解RESTful之前需要先了解一些REST

表述性状态传递（Representational State Transfer）
是一个标准，一种规范，遵循REST风格可以使开发的接口通用，便于调用者理解接口的作用

3.RESTful

基于REST的架构设计风格
RESTful API是基于REST的API设计理论
基于资源，增删改查都只是对于资源状态的改变
使用HTTP动词来操作资源

HTTP动词：

GET    用来获取资源，
POST  用来新建资源（也可以用于更新资源），
PUT    用来更新资源，
DELETE  用来删除资源

设计实践：

状态码：404、400、200、201、202、401、403、500等
错误码：自定义错误码
统一描述错误：错误码，错误信息，当前URL

请求：

REST 是面向资源的，这个概念非常重要，而资源是通过 URI 进行暴露。 URI
的设计只要负责把资源通过合理方式暴露出来就可以了。对资源的操作与它无关，操作是通过HTTP动词来体现，所以REST通过URI暴露资源时，会强调不要在URI中出现动词

错误写法：

GET /rest/api/getDogs 获取
GET /rest/api/addDogs 添加
GET /rest/api/editDogs/:dog_id 修改
GET /rest/api/deleteDogs/:dog_id 删除

正确写法：

GET /rest/api/dogs 获取
POST /rest/api/dogs 添加
PUT /rest/api/dogs/:dog_id 修改
DELETE /rest/api/dogs/:dog_id 删除

4.与传统API相比

4.1 URL

//获取
https://localhost:8080/myweb/getDogs <--> GET /rest/api/dogs 
//添加
https://localhost:8080/myweb/addDogs <--> POST /rest/api/dogs
//修改
https://localhost:8080/myweb/updateDogs/:dog_id <--> PUT /rest/api/dogs/:dog_id 
//删除
https://localhost:8080/myweb/deleteDogs/:dog_id <--> DELETE /rest/api/dogs/:dog_id

4.2 返回值

传统：

较为混乱，前端需要和后端对接返回错误码的意思

RESTful API：

格式固定，第一行永远是操作失败或者成功的状态码，第二行是返回的类型，第三行内容的长度，第五行开始是内容
这样我只需写一个程序解析返回的信息就可以了，可以重用，但是我们上面传统的不仅仅要协商，还有有不同的解析程序，稍微改变，就不能正常使用了。所以rest的明显更加通用。

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: xxx

{
   "url" : "/api/categories/1",
   "label" : "Food",
   "items_url" : "/api/items?category=1",
   "brands" : [
         {
            "label" : "友臣",
            "brand_key" : "32073",
            "url" : "/api/brands/32073"
         }, {
            "label" : "乐事",
            "brand_key" : "56632",
            "url" : "/api/brands/56632"
         }
         ...
   ]
}

一切随风