前后端交互和RESTful风格

[SherryLang]

最通俗易懂的解释

真的一看就懂了：

Server提供的RESTful API中，URL中只使用名词来指定资源，原则上不使用动词。“资源”是REST架构或者说整个网络处理的核心。比如：

• http://api.qc.com/v1/newsfeed: 获取某人的新鲜事;
• http://api.qc.com/v1/friends: 获取某人的好友列表;
• http://api.qc.com/v1/profile: 获取某人的详细信息;

用HTTP协议里的动词来实现资源的添加，修改，删除等操作。即通过HTTP动词来实现资源的状态扭转：GET 用来获取资源，POST 用来新建资源（也可以用于更新资源），PUT 用来更新资源，DELETE 用来删除资源。

比如：

• DELETE http://api.qc.com/v1/friends: 删除某人的好友 （在http parameter指定好友id）
• POST http://api.qc.com/v1/friends: 添加好友
• UPDATE http://api.qc.com/v1/profile: 更新个人资料
• 禁止使用： GET http://api.qc.com/v1/deleteFriend

作者：覃超 链接：https://www.zhihu.com/question/28557115/answer/48094438 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

RESTful Best Practices很好的一篇文章，先marked。

REST -- REpresentational State Transfer

首先，之所以晦涩是因为前面主语被去掉了，全称是 Resource Representational State Transfer，通俗来讲就是：

资源在网络中以某种表现形式进行状态转移

分解开来：

• Resource：资源，即数据（前面说过网络的核心）。比如 newsfeed，friends等；
• Representational：某种表现形式，比如用JSON，XML，JPEG等；
• State Transfer：状态变化。通过HTTP动词实现。

所以，REST就是：服务器生成包含状态转移的表征数据，用来响应客户端对于一个资源的请求；客户端借助这份表征数据，记录了当前的应用状态以及对应可转移状态的方式。当然，为了要实现这一系列的功能，一个不可或缺的东西就是超文本（hypertext）或者说超媒体类型（hypermedia type）。这绝对不是一个简简单单的媒体类型（例如，JSON属性列表）可以做到的。（参考：REST APIs must be hypertext-driven）

因此，像下面这种API

1、获取文章 请求： GET /blog/post/{postId} HTTP/1.1 响应：

HTTP/1.1 200 OK
{
    "title": "foobar",
    "content": "foobar",
    "comments": ["", "", ""]
}

2、发布文章 请求：

POST /blog/post HTTP/1.1
{
    "title": "foobar",
    "content": "foobar",
    "comments": ["", "", ""]
}

响应： HTTP/1.1 201 CREATED

绝对不是RESTful！ 绝对不是RESTful！ 绝对不是RESTful！ （重要的事情要说三遍）