一：为什么使用restful风格？
URL具有很强可读性的，具有自描述性（因为：路径中带有参数）
规范化请求过程和返回结果
资源描述与视图的松耦合
可提供OpenAPI，便于第三方系统集成，提高互操作性
提供无状态的服务接口，降低复杂度，可提高应用的水平扩展性
总结：1，restful是一种风格，或者说是规范，但不是标准。
看http method就知道干什么
看http status code就知道结果如何
我们一起来看看RESTFul API有哪些特点：
- 基于“资源”，数据也好、服务也好，在RESTFul设计里一切都是资源。
- 无状态。一次调用一般就会返回结果，不存在类似于“打开连接-访问数据-关闭连接”这种依赖于上一次调用的情况。
- URL中通常不出现动词，只有名词
- URL语义清晰、明确
- 使用HTTP的GET、POST、DELETE、PUT来表示对于资源的增删改查
- 使用JSON不使用XML
我举个例子：
网站：/get_user?id=3
RESTFul: GET /user/3 (GET是HTTP类型)
有些同学可能会说，GET、POST我也经常用啊。但是在网站里的GET和POST同RESTFul中的GET、POST是不一样的。网站里使用GET、POST的选择点在于，简单的用GET、复杂对象用POST；但在REST里，GET对应的是查询一个资源，而POST对应的是新增一个资源，意义是决然不同的。理解这一点非常重要。
好，我们接着来看一看RESTFul API的一些最佳实践原则：
- 使用HTTP动词表示增删改查资源， GET：查询，POST：新增，PUT：更新，DELETE：删除
- 返回结果必须使用JSON
- HTTP状态码，在REST中都有特定的意义：200，201,202,204,400,401,403,500。比如401表示用户身份认证失败，403表示你验证身份通过了，但这个资源你不能操作。
- 如果出现错误，返回一个错误码。比如我通常是这么定义的：
- API必须有版本的概念，v1，v2，v3
- 使用Token令牌来做用户身份的校验与权限分级，而不是Cookie。
- url中大小写不敏感，不要出现大写字母
- 使用 - 而不是使用 _ 做URL路径中字符串连接。
- 有一份漂亮的文档~（很重要）
以上只是列出了RESTFul的部分实践原则，并非全部。 给出一个典型的RESTFul API设计风格：
https://api.z.cn/v1/product/recent?page=3&size=20
以上URL非常容易理解，分页获取最新若干的Product资源。
最后，我们想聊一下，RESTFul API到底好用吗？某些情况好用，某些情况非常不好用。什么情况好用，什么情况不好用呢？
我的一个经验性的总结：对于开放的API，豆瓣、新浪微博、GitHub，好用，非常合适；对于内部开发，不好用。
基于资源型的RESTFul API 接口粒度和返回结果过于的“粗”，它通常返回的都是完整的数据模型，这对于客户端非常不友好。但开放API之所以开放，就是因为它不知道你到底需要什么返回结果，既然不知道，那么我干脆都返回给你。这样的好处是通用，但客户端不好处理。你只需要一个字段，服务器啪的丢给你十几个，作为客户端开发者你怎么想？
内部开发由于需求非常明确，通常来说服务器是不应该简单粗暴的直接甩资源实体给客户端的。那RESTFul API就不能接入到内部开发吗？当然不是，我们需要灵活一些借鉴RESTFul中的优点，来设计我们的内部API。那么如何简化，这就不是一篇文章能够说清楚的了，也没有一个统一的标准，需要自己去琢磨和体会。
最后举个例子吧，我个人在开发内部接口时会保留绝大多数的REST 特性，但我不会严格的只写增、删、改、查四个接口。必要的时候，还是要灵活处理一下。而且错误码、状态码这些非常优秀的特性，必须保留。
好了，关于RESTFul我们就介绍到这里。特别强调，接口设计是一个非常依赖于经验和重构的技术活儿，设计接口需要有一些艺术家的天赋（真实体会），你看GitHub的接口就非常的“美”。不要觉得很简单，真的比写代码还难。难道大家不觉得，有时候起名字真的是一件很难的事儿嘛？
作者：慕课网
链接：https://www.zhihu.com/question/28557115/answer/584744188
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。