标签：服务 18 09 URI Rest API 设计 Restful
Rest
Rest全称Representational State Transfer，即表述性状态转移，2000年提出，这时距HTTP1.1协议标准正式发布（1999年6月）仅一年的时间。
在一定的时间里SOAP满足了web服务的设计要求，达到了对外提供服务的目的，尽管协议十分晦涩，解析生硬。企业级的软件依然有很多保留着SOAP式的服务，一些政府系统依然保留着SOAP
Rest并不是一个标准或协议，而是一种设计风格，或者说是一个设计web服务的最佳实践，主要内容：
- 面向资源的URI设计，如user/register;
- 对资源的操作包括增、删、改、查（和数据库层的操作极为相似）；
- 连接具有无状态性，即每一次的响应只依赖于这一次的请求；
- 利用HTTP协议实现以上的设计思想。
非Restful的设计：
Restful的设计：
Rest设计
REST的设计利用了HTTP协议的请求选项，如GET、POST、PUT、DELETE。设计的简单示意图如下：
工作中最佳实践：
- 对选项的选择不应过多，不应死板教条，常用的有GET、POST即可；
- URI的设计应已名词为主、动词为辅，层次清晰；
- 参数的设计应已单词为主，少用多个词的驼峰连接形式；
- 功能与URI或者参数设计冲突时，应以功能实现为主。
Rest劣势
- 一千个读者，一千个哈姆雷特，在设计评审粗糙的情况下，面向资源的URI设计五花八门；
- URI泛滥，版本管理困难；
- HTTP 选项使用不当；
- REST API 参数、返回值设计不当；
…
微服务为什么选择Restful API
微服务组件拆分、服务解耦，各服务组件间的调用需要通过接口实现，Rest可以让这些服务风格统一、便于维护和管理；
服务层次化的前提是组件的拆分，如用户组件url前缀需要以 /user 开头，配置系统的前缀需要以 /configuration 开头，用程序自动对前缀校验
Restful API 的入参、出参，均以Java Bean的形式体现，称之为接口协议。业务接口协议可以继承用户组件协议，各业务协议之间不可以不可以继承和聚合，这些规则的设定，冗余的思想达到解耦的目的
标签：服务,18,09,URI,Rest,API,设计,Restful 来源： https://blog.csdn.net/yy_888888/article/details/120340468
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。