什么是RestFul格调 (什么是热搜,在哪看)
本文目录导航：
什么是RestFul格调
Restful格调，一种基于HTTP协定的软件架构设计，公用于构建网络运行的API。
此格调将数据与配置视为资源，并经常使用惟一URL标识资源。
客户端应用GET、POST、PUT、DELETE等HTTP方法对资源执行操作。
主机依据恳求方法及URL执行操作并前往资源示意。
其设计准则蕴含：1. 明白、易懂且易用的接口，优化了系统可裁减性和灵敏性。
现代Web服务中盛行驳回此设计思维。
举例说明，经常使用SpringMVC注解定义RESTful API，GET、POST、PUT、DELETE对应资源失掉、创立、降级、删除操作。
经过@RequestMapping指定URL门路，@PathVariable和@RequestBody失掉恳求参数。
以此，经过URL与HTTP方法操作产品资源，成功RESTful格调的API设计。
该格调的API设计确保了接口明晰、易于了解和经常使用，同时增强了系统的可伸缩性和灵敏性。
它是构建现代Web服务的抢手理念。
RESETful API接口设计规范
开发环节中，咱们常需提供API接口给客户端或第三方经常使用，如何构建易于了解的API至关关键。
若在设计API时遵照规范，开发环节中的沟通老本和效率将大大优化。
本文将讨论RESTful API的设计规范。
以下为贯通全文的几个关键术语：资源（单个对象的实例，如生物）、汇合（同类型对象的汇合，如生物们）、HTTP（网络通讯协定）、生产者（可动员HTTP恳求的客户端运行程序）、第三方开发者（非名目组成员但宿愿经常使用数据的开发者）、服务（可经过网络访问的HTTP服务/运行）、节点（主机上的API URL，可代表资源或整个汇合）、幂等性（无反作用，可屡次执行）、URL段（URL中由斜杠分隔的信息段）。
数据形象与设计：需确定数据库设计及提供的web服务配置，以启动API设计。
API应尽或者形象业务逻辑和数据，以便经常使用者轻松上手。
恳求方法：经常出现的HTTP恳求方法有GET（检索资源）和POST（创立资源）。
以下为四个半关键的HTTP动词：GET（检索）、POST（创立）、PUT（降级整个资源）、PATCH（降级资源属性）、DELETE（删除资源）。
此外，还有HEAD（检索元数据）和OPTIONS（检索操作信息）。
RESTful API应应用这些恳求方法启动交互，且URL段中不蕴含任何举措。
版本管理：运行的外围和数据关联相关会始终变动，因此API版本管理至关关键。
修正API或者造成向后不兼容，影响经常使用者。
为确保运行开展并满足经常使用者需求，需在引入新版本的同时保障旧版本的反常访问。
API剖析：继续跟踪客户端经常使用的API版本和端点信息，如每次恳求自增计数器。
跟踪API有助于保障罕用API的有效性。
API Root URL：API根地址对开发者至关关键。
坚持根入口点繁难可提高开发者接受度。
依据运行规模，API可搁置于子域或根域名下，并蕴含相关内容。
端点：端点指向特定资源或资源汇合的URL。
针对每个端点，需列出有效的HTTP动词和端点组合。
过滤器：当客户端恳求对象列表时，前往合乎查问条件的一切对象列表。
过滤器可最小化网络传输并放慢查问结果失掉。
形态码：经常使用适合的HTTP形态码对RESTful API至关关键。
经常出现形态码包括200 OK、201 CREATED、204 NO CONTENT等。
形态码范畴：1xx范畴形态码用于底层HTTP配置，2xx范畴形态码用于成功信息，3xx范畴形态码用于重定向，4xx范畴形态码用于客户端失误，5xx范畴形态码用于主机端失误。
预期前往文档：经常使用不同的HTTP动词执执行作时，生产者须要在前往中失掉某些信息。
典型的RESTful API包括GET、POST、PUT、PATCH、DELETE等操作。
认证：主机需确定启动恳求的用户身份。
OAuth2.0等认证方法可确保客户端安保访问API。
Content Type：大少数API提供JSON数据允许。
前往有效的数据格局可让开发者经常使用盛行的言语和框架启动解析。
超媒体API：超媒体API或者是RESTful API设计的未来。
它经过恳求API根失掉URL列表，每个URL都指向一个汇合，并形容客户端可了解的信息。
文档：API文档对开发者至关关键。
文档应面向一切开发者，确保易于了解，并提供完整的示例恳求和照应主体。
修订：原始的HTTP封装：HTTP恳求和照应都由键值对集组成，包括头部、恳求体、照应体等。
经常使用工具检查原始HTTP封装对API设计至关关键。
如何更好的设计RESTful API
一个好的RESTful API，应该具有以下特色：这个API应该是对阅读器友好的，能够很好地融入Web，而不是与Web貌合神离。
1.阅读器是最经常出现和最通用的REST客户端。
好的RESTful API应该能够经常使用阅读器+HTML成功一切的测试（不须要经常使用编程言语）。
这样的API还可以很繁难地经常使用各种智能化的Web配置测试、性能测试工具来做测试。
Web前端运行（基于阅读器的RIA运行、移动App等等）也可以很繁难地将多个RESTful API的配置组合起来，建造Mashup类的运行。
这个API中所蕴含的资源和关于资源的操作，应该是直观和容易了解的，并且合乎HTTP协定的要求。
REST开发又被称作“面向资源的开发”，这说明关于资源的形象，是设计RESTful API的外围内容。
RESTful API建模的环节与面向对象建模相似，是以名词为外围的。
这些名词就是资源，任何可命名的形象概念都可以定义为一个资源。
而HTTP协定并不是一种传输协定，它实践提供了一个操作资源的一致接口。
关于资源的任何操作，都应该映射到HTTP的几个有限的方法（罕用的有GET/POST/PUT/DELETE四个方法，还有不罕用的PATCH/HEAD/OPTIONS方法）下面。
所以RESTful API建模的环节，可以看作是具有一致接口解放的面向对象建模环节。
依照HTTP协定的规则，GET方法是安保且幂等的，POST方法是既不安保也不幂等的（可以用来作为一切写操作的通配方法），PUT、DELETE方法都是不安保但幂等的。
将对资源的操作正当映射到这四个方法下面，既不适度经常使用某个方法（例如适度经常使用GET方法或POST方法），也不减少过多的操作以致于HTTP的四个方法不够用。
2.假设发现资源上的操作过多，以致于HTTP的方法不够用，应该思考设计出更多的资源。
设计出更多资源（以及相应的URI）关于RESTful API来说并没有什么坏处。
这个API应该是松耦合的。
RESTful API的设计包括了三个墨守成规、由低到高的档次：资源形象、一致接口、超文本驱动。
正是这三个档次确保了RESTful API的松耦合性。
3.当设计面向互联网的API时，松耦合变成了一种“必定有”的强需求。
紧耦合的API十分软弱，一旦发布进来，主机端和客户端都不可继续退化。
尤其是主机端，发布进来的接口基本不敢改，改了之后，简直一切客户端运行立刻不可反常上班。
REST这种架构格调就是紧耦合API的解毒剂，这个话题可以谈的很深，这里就不开展了。
感兴味的读者可以参考《REST实战》。
这个API中所经常使用的表述格局应该是经常出现的通用格局在RESTful API中，关于资源的操作，是经过在主机端-客户端之间传递资源的表述来直接成功的。
资源的表述可以有很多种格局，并且在照应和恳求中的资源表述格局也会有所不同。
GET/POST照应中的资源表述格局，经常出现的有HTML、XML、JSON；POST/PUT恳求中的资源表述格局，经常出现的有规范的HTML表单参数、XML、JSON。
4.这些经常出现表述格局，解决起来十分容易，有少量的框架和库提供允许。
所以除非有很正当的要求，理论不须要经常使用自定义的私有格局。
经常使用HTTP照应形态代码来表白各种出错状况HTTP照应形态代码，是HTTP协定这个一致接口中用来表白出错状况的规范机制。
照应形态代码分红两局部：status code和reason phase。
两局部都是可定制的，也可以经常使用规范的status code，只定制reason phase。
5.假设一个所谓的“RESTful API”关于任何恳求都前往200 OK照应，在照应的信息体中前往出错状况信息，这种做法显然不合乎“确保操作语义的可见性”这个REST架构格调的基本要求。
这个API应该关于HTTP缓存是友好的6.充沛应用好HTTP缓存是RESTful API可伸缩性的基本。
HTTP协定是一个分层的架构，从两端的user agent到origin server之间，可以拔出很多两边组件。
而在整个HTTP通讯链条的很多位置，都可以设置缓存。
HTTP协定内建有很好的缓存机制，可以分红过时模型和验证模型两套缓存机制。
假设API设计者齐全没有思考过如何应用HTTP缓存，那么这个API的可伸缩性会有很多疑问。
phper