REST

REST, RESTful API 相关笔记
Representational State Transfer 表现状态转移

---

RESTful API规范

URI 规范：

一、URL 的命名 必须 全部小写

二、用中杠-不用下杠_；
应该使用连字符”-“来提高URL的可读性，而不是使用下划线”_”
为了使URL容易让人们理解，请使用连字符”-“字符来提高长路径中名称的可读性。
一些文本查看器为了区分强调URI，常常会在URI下加上下划线。这样下划线”_”字符可能被文本查看器中默认的下划线部分地遮蔽或完全隐藏。
为避免这种混淆，请使用连字符”-“而不是下划线

三、URL 中资源（resource）的命名 必须 是名词，并且 必须 是复数形式

godruoyi/restful-api-specification
https://github.com/godruoyi/restful-api-specification

RESTful API 设计指南 - 阮一峰
http://www.ruanyifeng.com/blog/2014/05/restful_api.html

HTTP动词

GET（SELECT）：从服务器取出资源（一项或多项）。
POST（CREATE）：在服务器新建一个资源。
PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。
DELETE（DELETE）：从服务器删除资源。

---

REST

REST是一种架构风格，其核心是面向资源；而webService底层SOAP协议，主要核心是面向活动；
RestFul利用HTTP请求方式进行HTTP方法（GET,POST,PUT,DELETE）的直接应用。
RestFul是一种约定，以资源为中心进行CRUD操作，它把网络上任何东西都看做是资源。
RestFul能通过HTTP形式直接调用，也可以基于JSON，SOAP通过XML传输。

REST 架构该怎么生动地理解？
https://www.zhihu.com/question/27785028

---

REST安全验证

对于基于WSDL和SOAP的Web Service，我们有WS-Security这样的安全规范来指导实现认证、授权、身份管理等安全需求。那么，RESTful API有无成熟可用规范或实现框架呢？如何保证RESTful API的安全性呢？

HTTP Basic(base64编码)

REST由于是无状态的传输，所以每一次请求都得带上身份认证信息，身份认证的方式，身份认证的方式有很多种，第一种便是http basic，这种方式在客户端要求简单，在服务端实现也非常简单，只需简单配置apache等web服务器即可实现，所以对于简单的服务来说还是挺方便的。但是这种方式安全性较低，就是简单的将用户名和密码base64编码放到header中。
正是因为是简单的base64编码存储，切记切记在这种方式下一定得注意使用ssl，不然就是裸奔了。

Http Basic 是一种比较简单的身份认证方式。 在 Http header 中添加键值对 Authorization: Basic xxx （xxx 是 username:passowrd base64 值）。
例如 username 为 zmk ，password 为 123456，请求则如下
GET /auth/basic/ HTTP/1.1
Host: xxxxx
Authorization: Basic em1rOjEyMzQ1Ng==
而Base64 的解码是非常方便的，如果不使用 Https ，相当于是帐号密码直接暴露在请求中。
危险性高，实际开发者使用的应该几乎为0。

HTTP Digest

顺便提下 DIGEST 认证，和 BASIC 认证相差无几，而且不适合 api 设计，实际又需要两次请求，首次请求，服务器端返回401，并且带上 nonce 值，然后客户端再利用 username + password + nonce 默认MD5之后再请求。对 http 请求的作用是仅仅防止二次请求，对身份认证并没有什么提升。

API KEY

API Key就是经过用户身份认证之后服务端给客户端分配一个API Key

client端向服务端注册，服务端给客户端发送响应的api_key以及security_key，注意保存不要泄露，然后客户端根据api_key,secrity_key,timestrap,rest_uri采用hmacsha256算法得到一个hash值sign，构造途中的url发送给服务端。

服务端收到该请求后，首先验证api_key,是否存在，存在则获取该api_key的security_key，接着验证timestrap是否超过时间限制，可依据系统成而定，这样就防止了部分重放攻击，途中的rest_api是从url获取的为/rest/v1/interface/eth0,最后计算sign值，完之后和url中的sign值做校验。这样的设计就防止了数据被篡改。

通过这种API Key的设计方式加了时间戳防止了部分重放，加了校验，防止了数据被篡改，同时避免了传输用户名和密码，当然了也会有一定的开销。

Oauth

OAuth协议适用于为外部应用授权访问本站资源的情况。其中的加密机制与HTTP Digest身份认证相比，安全性更高。使用和配置都比较复杂

JWT(Json Web Token)

JWT 是JSON Web Token，用于发送可通过数字签名和认证的东西，它包含一个紧凑的，URL安全的JSON对象，服务端可通过解析该值来验证是否有操作权限，是否过期等安全性检查。由于其紧凑的特点，可放在url中或者 HTTP Authorization头中

RESTFUL API 安全设计
https://blog.csdn.net/degwei/article/details/51489391

RESTful Api 身份认证安全性设计
http://www.phpabc.cn/restful-api-shen-fen-ren-zheng-an-quan-xing-she-ji.html

如何设计好的RESTful API之安全性
https://blog.csdn.net/ywk253100/article/details/25654101

---

webservice与rest对比

何时使用REST：
若本身只是简单的CRUD业务操作，那么抽象资源就比较容易。
而对于复杂的业务活动抽象资源并不是一个简单的事情，比如校验用户等级，转账，事务处理等。
何时使用SOAP：
若有严格的规范和标准定义要求，且前期需要指导多个业务系统集成和开发的时，
因SOAP风格有清晰的规范标准定义，SOAP更适合。
我们可以在开始和实现之前就严格定义相关的接口方法和接口传输数据。

SOAP 不仅像 REST 一样支持 SSL，而且还支持增加了很多企业级安全特性的 WS-Security

REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。

一句话：简单数据操作，无事务处理，开发和调用简单使用REST架构风格较好。

【接口开发】浅谈 SOAP Webserver 与 Restful Webserver 区别
https://www.cnblogs.com/hyhnet/archive/2016/06/28/5624422.html

REST Vs SOAP，Soap 和 Rest 的区别
http://blog.csdn.net/defonds/article/details/49000993

---