整理-restful风格-URI设计可以遵循的10条原则

restFul理论知识

• " 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构"。
• “REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例”
• “要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform Resource Identifier)。URI既可以看成是资源的地址，也可以看成是资源的名称。”
• “URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联。”

URI设计的一些原则

• 如何才能让"URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联"呢?最基本,可以把握如下原则

1. post、get、put、delete包含不同的含义。

2.post、get、put、delete的构成了资源CRUD。

3.uri中可以不用出现save、delete、update、findAll等关键字,只需要合理使用不同请求法方式即可。

传统：http://localhost:8080/user/save
REST：http://localhost:8080/user POST 执行保存

传统：http://localhost:8080/user/delete?id=1
REST：http://localhost:8080/user/1 DELETE 执行删除

传统：http://localhost:8080/user/update?id=1
REST：http://localhost:8080/user/1 PUT 执行更新 1就是id

传统：http://localhost:8080/user/findAll
REST：http://localhost:8080/user GET 查所有

4.路径本身就可以传递参数,不用一定需要?key=value形式

传统：http://localhost:8080/user/delete?id=1
REST：http://localhost:8080/user/1 DELETE 执行删除

5._或-来让URI可读性更好

越多的网站使用_或-来分隔一些单词，让URI看上去更为人性化。 例如国内比较出名的开源中国社区，它上面的新闻地址就采用这种风格， 如http://www.oschina.net/news/38119/oschina-translate-reward-plan

6.使用/来表示资源的层级关系

https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08

就表示了一个多级的资源， 指的是git用户的git项目的某次提交记录，又例如/orders/2012/10可以用来表示2012年10月的订单记录。

7.?用来过滤资源

/pulls?state=closed用来表示git项目中已经关闭的推入请求， 这种URL通常对应的是一些特定条件的查询结果或算法运算结果。

8.,或;可以用来表示同级资源的关系

哪天github可以比较某个文件在随意两次提交记录之间的差异，或许可以使用/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08;bd63e61bdf38e872d5215c07b264dcc16e4febca作为URI。

9.版本号可以在HTTP请求头信息的Accept字段中进行区分

http://www.example.com/app/foo

不同版本请求头

Accept: vnd.example-com.foo+json; version=1.0
Accept: vnd.example-com.foo+json; version=1.1
Accept: vnd.example-com.foo+json; version=2.0

# 10.uri不包含动作

URI包含动词(正确的写法是把动词transfer改成名词transaction),因为post本生就包含具体的动作。

错误:
POST /accounts/1/transfer/500/to/2
正确:
POST /accounts/1/transaction/500/to/2

同样如下也是错误的

GET /getUser/1
POST /createUser
PUT /updateUser/1
DELETE /deleteUser/1

参考:https://www.runoob.com/w3cnote/restful-architecture.html