rest服务与restful Api的理解

ゞ浴缸里的玫瑰 2022-10-01 14:50 347阅读 0赞

最近总是听同事们谈及rest服务与restful 接口,但是与我了解的含义有些出入,所以花了些时间整理并理解到底什么是rest ? 什么是restful 接口?  
一.什么是rest?

> Representational State Transfer，简称REST,RoyFielding博士在2000年他的博士论文中提出来的一种**软件架构风格**。它是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。

[百度百科][Link 1]  
[维基百科][Link 2]  
总之rest就是一种设计风格 , 而不是一种深奥的技术!!!,满足这些约束条件和原则的应用程序或设计就是 RESTful。

**我们一起来看看RESTFul API有哪些特点：**

*  基于“资源”，数据也好、服务也好，在RESTFul设计里一切都是资源。
 *  无状态。一次调用一般就会返回结果，不存在类似于“打开连接-访问数据-关闭连接”这种依赖于上一次调用的情况。http请求一样
 *  URL中通常不出现动词，只有名词
 *  URL语义清晰、明确
 *  使用HTTP的GET(获取)、POST(创建)、DELETE(删除)、PUT(更新)来表示对于资源的增删改查
 *  出参使用JSON不使用XML

**我们接着来看一看RESTFul API的一些最佳实践原则：**

*  使用HTTP动词表示增删改查资源， GET：查询，POST：新增，PUT：更新，DELETE：删除
 *  返回结果必须使用JSON
 *  HTTP状态码，在REST中都有特定的意义：200，201,202,204,400,401,403,500。比如401表示用户身份认证失败，403表示你验证身份通过了，但这个资源你不能操作。
 *  如果出现错误，返回一个错误码  
    [restful风格接口文档参考][restful]

**restful风格的接口真的好吗?**  
我的一个经验性的总结：对于开放的API，豆瓣、新浪微博、GitHub，好用，非常合适；对于内部开发，不好用。  
基于资源型的RESTFul API 接口粒度和返回结果过于的“粗”，它通常返回的都是完整的数据模型，这对于客户端非常不友好。但开放API之所以开放，就是因为它不知道你到底需要什么返回结果，既然不知道，那么我干脆都返回给你。这样的好处是通用，但客户端不好处理。你只需要一个字段，服务器啪的丢给你十几个，作为客户端开发者你怎么想？

内部开发由于需求非常明确，通常来说服务器是不应该简单粗暴的直接甩资源实体给客户端的。那RESTFul API就不能接入到内部开发吗？当然不是，我们需要灵活一些借鉴RESTFul中的优点，来设计我们的内部API。那么如何简化，这就不是一篇文章能够说清楚的了，也没有一个统一的标准，需要自己去琢磨和体会。  
最后举个例子吧，我个人在开发内部接口时会保留绝大多数的REST 特性，但我不会严格的只写增、删、改、查四个接口。必要的时候，还是要灵活处理一下。而且错误码、状态码这些非常优秀的特性，必须保留。  
参考:[https://www.cnblogs.com/mq0036/p/9105536.html][https_www.cnblogs.com_mq0036_p_9105536.html]

[Link 1]: https://baike.baidu.com/item/rest/6330506?fr=aladdin
[Link 2]: https://en.wikipedia.org/wiki/Representational_state_transfer
[restful]: https://my.oschina.net/wangmengjun/blog/907679
[https_www.cnblogs.com_mq0036_p_9105536.html]: https://www.cnblogs.com/mq0036/p/9105536.html