他希望能基于网络现有的协议基础上创建一个功能强大，性能游戏，适宜通信的架构。
如含义一样，将从逻辑上将业务实现拆分为客户端与服务端实现。
通过分离设计，能简化两边的设计复杂度，提高其可扩展性。
资源是 RESTful 的主体，主要指代互联网上的一个实体，可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。资源通过 URI 来唯一标识。
资源的信息载体形式，叫做表现层。他可段棚以是文本、XML、JSON 或者是一个二进制文件。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。
互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端汪闷想要 *** 作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层握陵则状态转化"。
在 HTTP 中，我们一般通过四种 HTTP 动词（verb）来对应资源的变化：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
相应的状态的交互应当是无状态的（ServerLess）这是 HTTP 的特性所决定的，要求每次请求包含服务器需要的所有信息，这样可以很好的确保每一次变化的可预测性，进而提高可靠性，也能增进可扩展性。
综合上面的解释，我们总结一下什么是RESTful架构：
（1）每一个URI代表一种资源；
（2）客户端和服务器之间，传递这种资源的某种表现层；
（3）客户端通过四个HTTP动词，对服务器端资源进行 *** 作，实现"表现层状态转化"。
HTTP 请求是互联网架构中重要的一环，其在 TCP 连接的基础上，实现了语义化，缓存机制，无状态等等特性。在互联网上也有不错的性能，REST 常常会基于 HTTP 协议的基础上实现其核心概念。
论文中对 HTTP 与 REST 相适宜的论述提及了几点：
这里是论文中对 HTTP Code 来表现业务相应状态的相关表述：
原文： https://martinfowler.com/articles/richardsonMaturityModel.html
他讲这个模型层次分为四级，大概如下所示：
利用 HTTP 协议做数据交换，所有的参数描述通过 url 或者 POST body 形式通知服务器，返回相应的数据，此级别通常都是基于 。实质上就是基于 HTTP 的 RPC（远程过程调用），具体交付的细节完全由相关规范或团队内部约定解决。
根据理解设计了一份请求交互：
将 API 按照 RESTful 中资源的方式进行划分，初步有了自我描述（self description）的特性了，客户端可以对相关的资源进行更加细致的 *** 作。
根据理解设计了一份请求交互：
这个级别有更加进一步的利用了 HTTP 的特性，增加了对 HTTP verb （比如 GET 表示查询、POST 表示创建、PUT 表示修改、DELETE 表示 等等）的运用，并且运用原有的 HTTP response status 来表征业务上请求的成功与失败，一般项目常见的 RESTful 运用基本都接近这个级别。
这个请求基本就和我们平时使用的 RESTful api 很接近了：
这个基本也称作 HATEOAS (Hypertext As The Engine Of Application State)，这个级别是 RESTful 最复杂的实现，这个级别最理想的情况是，不需要特别复杂 API 文档进行描述的，这里的 API 设计最大化的实现了 RESTful 的自我描述特性。这种方案虽然引入很大的复杂性，但是最大限度的将 API 设计变得配置化了，所有 API 设计将会基于更加抽象的工作流设计了，稍后再做解释：
本阶段的相关请求模型大概是这样的：
可以看出，从查询到最终结果，都是由第一个 api 的返回的资源列表和 *** 作项，引导向后面的 *** 作，这样，后端在设计 API 的时候，需要考虑从一条业务 workflow 的角度去设计。这样只要整个流程不变，局部的数据变化，只需要修改后端的相关配置即可，这样业务可以很大程度的配置化。
不太清楚你写这个借口的目的是什么，一般我们做上传和侍都是前端通过控件上传后得到路径，然后调用一个方法将路径保存就可以了。你这个借口的目的是什么？先调用接口获得路径是保存路径不一样的森蠢情况才这样做的。如果上传的路径是一样此棚陪的就没有那个必要再去调用一次了
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）