标签：类型 intern providing header html tostring 没有 带宽 href
Note GET, primarily used to select resources. Other options for an API method include: POST, primarily used to create child resources. PUT, primarily used to update existing resources (and, although not recommended, can be used to create child resources). DELETE, used to delete resources. PATCH, used to update resources. HEAD, primarily used in testing scenarios. It is the same as GET but does not return the resource representation. OPTIONS, which can be used by callers to get information about available communication options for the target service. The method created is not yet integrated with the back end. The next step sets this up.
目录：
RESTful 是什么 阮一峰：理解RESTful架构
State Transfer，状态转移
client <-> server，这个交互涉及到数据和状态的变化。
client 操作 server，即通过某种手段（HTTP method），使 server 发生状态转移。
目前对 REST 的理解：(2016-8-20)
HTTP verbs 推荐返回的状态码
200 OK 201 Created 204 No Content304 Not Modified400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 409 Conflict500 Internal Server ErrorJSON-Server
来看一组 JSON-Server 提供的 RESTful API 接口:
GET /posts //获取posts下的所有资源
GET /posts/1 //获取posts下id为1的资源
GET /posts?title=json-server&author=typicode //获取posts下title=json-server&author=typicode的资源
POST /posts //posts添加操作,非幂等，每次都添加新的，除非已存在！创建资源成功时，应当返回201 Created而不是200 OK。同时，需要在HTTP response headers的location节中返回所创建的新资源对应的URL，同时返回该资源的内容。
PUT /posts/1 //对posts下id为1的资源进行修改操作：完全替换，或者不存在则新增。官方的定义，使用PUT方法，意味着或者不存在该资源，则创建一个新的资源；或者存在该资源，使用新的资源完整替换原有资源。无论哪一种，多次操作后得到的系统状态的结果是完全一致的，因而符合幂等性。资源的标识在方法中，通过参数id独立传递，ProductInput并不包含id属性。在更新前，需要判断id对应的资源是否存在，然后进行进一步的操作。
PATCH /posts/1 //对posts下id为1的资源进行修改操作：局部更新
DELETE /posts/1 //对posts下id为1的资源进行删除操作
使用时需注意：
get
将查询的参数用 & 拼接成查询字符串
if(data && Object.prototype.toString.call(data) == "[object Object]") {
for (var i in data) {
dataStr += i + "=" + data[i] + "&";
}
}
lastPos = dataStr.lastIndexOf("&");
dataStr = dataStr.slice(0, lastPos);
在 post put patch 请求中，content-type的值必须为 application/json
相应的，需要将提交的数据，由 JS对象 -> JSON JSON.stringify()
xhr.setRequestHeader("content-type", "application/json");
xhr.send(data ? JSON.stringify(data) : null);
RESTful
RESTful 只是一种 architectural style，意思是如果大家都依此行事的话，沟通成本会很低，开发效率就高。
那么只要前后台约定好，就可以随意选取方法了么？
This is wrong because a request passes through many intermediaries and middleware applications which perform optimizations based on the HTTP method type. These optimizations depend on two key characteristics of HTTP methods: idempotency and safety, which are defined in the HTTP specification.
Code Ahoy: REST Design - Choosing the Right HTTP Method
从这个角度来说，对哪种操作使用哪种方法，取决于 HTTP 方法本身的特性 和 前后台交互接口的约定。
HTTP 方法的两个关键特性：安全|幂等 （safe|idempotent）
safeidempotent
幂等的方法保证了重复进行一个请求和一次请求的效果相同。（并不是指返回 client 的响应总是相同的；而是指 server 上资源的状态从第一次请求后就不再改变）
在数学中，幂等性指N次变换和一次变换的结果相同。
x = 1; /* 幂等 */
x++; /* 非幂等 */
安全|幂等 是由 HTTP 标准定义的契约：开发者在实现 RESTful API 时必须遵守。
当使用 HTTP 构建 RESTful 程序时，对HTTP method 的实现应该满足其安全性和幂等性，来使 client 和中间件能自由地按契约优化，并增强用户体验。
e.g. 浏览器并不确切知道某个特定的 form 用途，但如果这个 form 是通过 HTTP GET 提交的，浏览器就会知道当出现网络异常的时候，它可以安全的、自动再次尝试提交。 而通过 HTTP POST 提交的 form，如果浏览器不先向用户确认就重复提交，会是不安全的。
RESTful 下的 post put patch
post
从另一个角度理解 POST 如何设计下单的接口？post /orders ?
本来 POST 就是被设计来提交表单这样的事务型操作的。所以 POST 可以理解为执行服务器的一个事务。POST 请求服务器执行一个动作，多次发起请求可能导致动作多次执行：非幂等。
put
patch
patch 可以对资源进行逻辑判断增量修改，如每次加3，那么执行多次，就会造成额外影响。有人认为应该用 POST 来创建新资源，用 PUT 来更新已有资源。如果用 POST 来做更新操作，就不符合 RESTful 风格。
实际并非如此。
The REST standard doesn’t stop us from using POST requests for updates. In fact, it doesn’t even talk about it because idempotency and safety guarantees are properties of the HTTP protocol, not of the REST standard.
作者 Code Ahoy 又引用了 Roy Fielding 的话， 大意是，例如 RESTful 不使用 GET 来进行不安全的操作，是因为这会违反 HTTP 中对 GET 方法的定义，反过来就会影响中间件和搜索引擎。由 HTTP 定义的方法是 Web‘s architecture definition 的一部分，而不属于 REST architecture style.
因此，使用 POST 还是 PUT 归结于：这些方法的幂等性保证。
因为 PUT 是幂等的，所以当第一个请求的响应没有及时到达的时候，clients 或者中间件可以重复发送 PUT 请求，而不用考虑 server 是否已经处理了第一个请求。 而为了保证幂等性，PUT 请求必须替换整个资源，因此必须发送所有属性。 如果要进行局部更新，就必须使用 POST 或者 PUT 这些非幂等的方法。
HTTP 中的 POST V.S. PUT
The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request – the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. Method Definitions RFC2616
POST 和 PUT 最根本的区别反映在 request URI 的含义上：
PUT
PUT puts a file or resource at a specific URI, and exactly at that URI.
如果这个这个 URI 所指定的位置上已有资源，PUT 就会替换掉这个资源；如果没有， PUT 会创建一个。
但是 PUT 请求的响应不会被缓存。
POST
POST sends data to a specific URI and expects the resource at that URI to handle the request.
POST 请求的响应的是可以缓存的，只要 server 设置了合适的 Cache-Control 和 Expires 首部。
HTTP RFC 指定 POST 用来：
使用 REST 的好处之一就是促进了 HTTP verbs/methods 的正确使用。
最后来归纳一下：
POSTto a URL creates a child resource at a server defined URL.PUTto a URL creates/replaces the resource in its entirety at the client defined URL.PATCHto a URL updates part of the resource at that client defined URL.
post put
创建的对象，其URL是由 client 命名，还是 server？server 决定 - post；client 命名 - put.
如果只是知道这个资源的父级类别的 URL，用 post；（比如说创建的资源id是数据库中自增长的）；
POST /expense-report
换句话说，如果知道将要创建的资源的 URL，用 put；
PUT /expense-report/10929
put 是创建时的一个候选方法：当 client 在资源创建前就已经知道了它的URL。
put patch
put 用来对已知资源做完全替换，要求前端提供一个完整的资源对象，缺了的字段会被清空。patch 做局部更新，后台只会更新接收到的字段。【节省带宽】
http://www.cnblogs.com/xhz-dalalala/p/5791631.html
标签：类型 intern providing header html tostring 没有 带宽 href
原文地址：https://www.cnblogs.com/x-poior/p/13292600.html
