㈠ 怎样理解restful格式中的uri
REST -- REpresentational State Transfer 直接翻译：表现层状态转移。这个中文直译经常出现在很多博客中。尼玛谁听得懂“表现层状态转移”？这是人话吗？我自己也困惑了很久，查询了很多资料，花了差不多一年有个还算清晰的理解。分享如下：
Ivony 老师的一句话概括很精辟：
URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。
--- 简洁版 ---
0. REST不是"rest"这个单词，而是几个单词缩写。但即使那几个单词说出来，也无法理解在说什么 -_-!! （不是要贬低人，是我自己也理解困难）；
1. REST描述的是在网络中client和server的一种交互形式；REST本身不实用，实用的是如何设计 RESTful API（REST风格的网络接口）；
2. Server提供的RESTful API中，URL中只使用名词来指定资源，原则上不使用动词。“资源”是REST架构或者说整个网络处理的核心。
㈡ 在restful api 设计中，如果要获得一个资源，一定要用GET方法么
不一定，post同样也可以，只是查询的接口一般约定为get，修改用put，增加记录用post，删除用delete
㈢ restful api接口规范是什么
REST（REpresentationStateTransfer）描述了一个架构样式的网络系统，比如web应用程序。
一般依赖于HTTP认证，HTTP认证有几种：basic，digest，token，这些都有标准的实现的开源包需要主要的是这个认证的帐号跟你业务的帐户实际是不一样的。REST属于webService一种，安全是后台服务的安全，因此不需要实际的业务帐号，通常是系统keyStore证书库里的账户。
RESTFUL特点包括：
1、每一个URI代表1种资源。
2、客户端使用GET、POST、PUT、DELETE4个表示操作方式的动词对服务端资源进行操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
3、通过操作资源的表现形式来操作资源。
4、资源的表现形式是XML或者HTML。
5、客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息。
㈣ 如何设计好的RESTful API
规划好你的API的外观要先于开发它实际的功能。首先你要知道数据该如何设计和核心服务/应用程序会如何工作。如果你纯粹新开发一个API，这样会比较容易一些。但如果你是往已有的项目中增加API，你可能需要提供更多的抽象。
有时候一个集合可以表达一个数据库表，而一个资源可以表达成里面的一行记录，但是这并不是常态。事实上，你的API应该尽可能通过抽象来分离数据与业务逻辑。这点非常重要，只有这样做你才不会打击到那些拥有复杂业务的第三方开发者，否则他们是不会使用你的API的。
当然你的服务可能很多部分是不应该通过API暴露出去的。比较常见的例子就是很多API是不允许第三方来创建用户的。
GET (选择）：从服务器上获取一个具体的资源或者一个资源列表。
POST（创建）：在服务器上创建一个新的资源。
PUT（更新）：以整体的方式更新服务器上的一个资源。
PATCH（更新）：只更新服务器上一个资源的一个属性。
DELETE（删除）：删除服务器上的一个资源。
还有两个不常用的HTTP动词：
HEAD：获取一个资源的元数据，如数据的哈希值或最后的更新时间。
OPTIONS：获取客户端能对资源做什么操作的信息。
一个好的RESTful API只允许第三方调用者使用这四个半HTTP动词进行数据交互，并且在URL段里面不出现任何其他的动词。
一般来说，GET请求可以被浏览器缓存（通常也是这样的）。例如，缓存请求头用于第二次用户的POST请求。HEAD请求是基于一个无响应体的GET请求，并且也可以被缓存的。
㈤ 什么是REST API
REST 是REpresentational State Transfer的缩写，字面的翻译是表现层状态转移。
RESTful API就是REST风格的网络接口，REST描述的是在网络中client和server的一种交互形式；REST本身不实用，实用的是如何设计。
Server提供的RESTful API中，URL中只使用名词来指定资源，原则上不使用动词。“资源”是REST架构或者说整个网络处理的核心。
拓展资料:
REST指一组架构约束条件和原则，满足约束条件和原则的应用程序设计。架构，软件体系结构分为三部分：构建，用于描述计算机；连接器，用于描述构建的链接部分；配置将构建和连接器组成有机整体。
web基本技术：
URI（统一资源标示符）HTTP（超文本传输协议）（post、get、put、delete） Hypertext。
1、每个资源都应该有唯一的一个标识
2、使用标准的方法更改资源的状态
3、request和response的自描述
4、资源多重表述
5、无状态服务
用HTTP协议里的动词来实现资源的添加，修改，删除等操作。即通过HTTP动词来实现资源的状态扭转：
GET 用来获取资源
POST 用来新建资源（也可以用于更新资源）
PUT 用来更新资源，
DELETE 用来删除资源。
㈥ 如何理解rest和restful，什么是restfulAPI
简单理解一
就是用URL定位资源，用HTTP描述操作。
简单理解二
URL定位资源，用HTTP动词(GET,POST,DELETE,DETC)描述操作。
官方定义
一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。
以web开发举例
在设计web接口的时候，REST主要是用于定义接口名，接口名一般是用名次写，不用动词，那怎么表达“获取”或者“删除”或者“更新”这样的操作呢——用请求类型来区分。
比如，我们有一个students接口，对于“学生”我们有增删改查四种操作，怎么定义REST接口？
增加一个学生，uri: http://testcode.com/school/students 接口类型：POST
删除一个朋友，uri: http://testcode.com/school/students 接口类型：DELETE
修改一个朋友，uri: http://testcode.com/school/students 接口类型：PUT
查找朋友，uri: http://testcode.com/school/students 接口类型：GET
上面我们定义的四个接口就是符合REST协议的，请注意，这几个接口都没有动词，只有名词students，都是通过Http请求的接口类型来判断是什么业务操作。
举个反例
uri: http://testcode.com/school/addStudents 该接口用来表示增加学生，这就是不符合REST协议的接口。
建议
用HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功，500 表示Server内部错误，403表示Bad Request等。(反例：传统web开发返回的状态码一律都是200，其实不可取。)
REST风格接口意义
前后端分离。前端拿到数据只负责展示和渲染，不对数据做任何处理。后端处理数据并以JSON格式传输出去，定义这样一套统一的接口，在web，ios，android三端都可以用相同的接口，节约开发成本以及便于同一调试。
㈦ 我是一个人么，还有人觉得 RESTful 是糟糕的设计么
我主要写后端代码，以前写 PHP, 现在写 Node.js. 刚听说 RESTful 的时候，觉得很高端大气上档次，很理想很美好。但在后来的实践中发现 RESTful 很大程度上拖慢了后端的开发速度，而对前端(AngularJS)的开发速度改善也很有限。
RESTful 希望将所有请求都包装成对资源的新增，读取，修改，以对应不同的 HTTP 动词，但是并非所有请求都可以归到前面几类，既然无法将所有请求都 RESTful 化，甚至无法将大部分的请求 RESTful 化，那么意义就很有限了，会导致花费大量时间斟酌 API 应该如何设计。
RESTful 将一部分参数放到了 URL 里，还有一部分参数在 Header 里，从 URL 和 Header 里分离参数，虽然有库的辅助，但是我觉得很麻烦。
RESTful 通过 Status Code 来表示结果状态，但是通常的情况下，结果只有成功和出错两种情况，出错的情况分很多种，原因都很复杂，即使有 Status Code 依然需要有一个字符串来描述错误详情，所以 Status Code 在这里就显得很多余了。
所以我现在开始坚定地黑 RESTful, 我认为“传统”的 API 设计才是最可行的，即：
* URL 是一个动词，其中不包含参数。
* 没有副作用的请求可以用 GET, 其余必须 POST
* POST 时用正文传递参数，GET 时用 Query String 传递参数
* Status Code 为 200 或 400, 后者会返回一个字符串形式的错误代号。
这个？
㈧ REST 架构该怎么生动地理解
相同问题一起答了！
我觉得问题很好，我自己去年创业的时候去学习REST和尝试着设计RESTful API，一直觉得它的文档晦涩难懂，国内也没有找到太好文章。后来一年内反复琢磨了好几遍，和FB+Square的朋友讨论过好几次，有了一个比较清晰的总结。分享如下：
@Ivony 老师的一句话概括很精辟：
URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。
--- 简洁版 ---
0. REST不是"rest"这个单词，而是几个单词缩写。但即使那几个单词说出来，也无法理解在说什么 -_-!! （不是要贬低人，是我自己也理解困难）；
1. REST描述的是在网络中client和server的一种交互形式；REST本身不实用，实用的是如何设计 RESTful API（REST风格的网络接口）；
2. Server提供的RESTful API中，URL中只使用名词来指定资源，原则上不使用动词。“资源”是REST架构或者说整个网络处理的核心。比如：
api.qc.com/v1/newsfeed: 获取某人的新鲜;
api.qc.com/v1/friends: 获取某人的好友列表;
api.qc.com/v1/profile: 获取某人的详细信息;3. 用HTTP协议里的动词来实现资源的添加，修改，删除等操作。即通过HTTP动词来实现资源的状态扭转：
GET 用来获取资源，
POST 用来新建资源（也可以用于更新资源），
PUT 用来更新资源，
DELETE 用来删除资源。