大家好，今日小深来为大家解答以上的问题。patch请求，patch请求demo很多人还不知道，现在让我们一起来看看吧！

patch请求(patch请求demo)patch请求(patch请求demo)


patch请求(patch请求demo)


1、break;设计时通过将请求和响应之间的不同部分隔离来让事情变得简单。

2、保持简单的规则让我们能更关注在一些更大的更困难的问题上。

3、一般来说响应也是分为三个部分。

4、请求和响应将解决一个特定的资源或。

5、使用路径（path）来表明身份，body来传输内容（content）还有头信息（header）来传递元数据（metadata）。

6、查询参数同样可以用来传递头信息的内容，但头信息是，因为他们更灵活、更能传达不同的信息。

7、所有的访问API行为，都需要用TLS通过安全连接来访问。

8、没有必要搞清或解释什么情况需要TLS 什么情况不需要TLS，直接强制任何访问都要通过 TLS。

9、理想状态下，通过拒绝所有非TLS请求，不响应或80端口的请求以避免任何不安全的数据交换。

10、如果现实情况中无法这样做，可以返回403 Forbidden响应。

11、把非TLS的请求重定向(Redirect)至TLS连接是不明智的，这种含混/不好的客户端行为不会带来明显好处。

12、依赖于重定向的客户端访问不仅会导致双倍的负载，还会使 TLS 加密失去意义，因为在首次非TLS调用时，敏感信息就已经暴露出去了。

13、制定版本并在版本之间平缓过渡对于设计和维护一套API是个巨大的挑战。

14、所以，在设计之初就使用一些方法来预防可能会遇到的问题。

15、适合放置版本号的位置是头信息(HTTP Headers)，在 Accept 段中使用自定义类型(contenttype)与其他元数据(metadata)一起提交。

16、例如:在所有返回的响应中包含ETag头信息，用来标识资源的版本。

17、这让用户对资源进行缓存处理成为可能，在后续的访问请求中把If-None-Match头信息设置为之前得到的ETag值，就可以侦测到已缓存的资源是否需要更新。

18、为每一个请求响应包含一个Request-Id头，并使用UUID作为该值。

19、通过在客户端、或任何支持服务上记录该值，它能为我们提供一种机制来跟踪、诊断和调试请求。

20、一个大的响应应该通过多个请求使用Range头信息来拆分，并指定如何取得。

21、详细的请求和响应的头信息（header），状态码(status code)，范围(limit)，排序(ordering)和迭代(iteration)等，参考 Heroku PlatformAPI discussion of Ranges .在 PUT/PATCH/POST 请求的正文（request bodies）中使用JSON格式数据，而不是使用form 表单形式的数据。

22、这与我们使用JSON格式返回请求相对应，例如:资源名 （Resource names）:使用复数形式为资源命名，除非这个资源在系统中是单例的 (例如，在大多数系统中，给定的用户帐户只有一个)。

23、 这种方式保持了特定资源的统一性。

本文到这结束，希望上面文章对大家有所帮助。