RESTful架构风格概述.docx

在移动互联网的大潮下，随着docker等技术的兴起，『微服务』的概念也越来越被大家接受并应用于实践，日益增多的web service逐渐统一于RESTful架构风格，如果开发者对RESTful架构风格不甚了解，则开发出的所谓RESTful API总会貌合神离，不够规范。本文是我对RESTful架构风格的一些理解，和大家分享一下，如果有问题，欢迎讨论。Outline1. RESTful架构风格1.1 RESTful架构风格的特点1.1.1 资源1.1.2 统一接口1.1.3 URI1.1.4 无状态1.2 ROA、SOA、REST与RPC1.3 本真REST与hybrid风格2. 认证机制2.1 Basic Auth2.2 Token Auth2.3 OAuth3. 总结1. RESTful架构风格RESTful架构风格最初由Roy T. Fielding（HTTP/1.1协议专家组负责人）在其2000年的博士学位论文中提出。HTTP就是该架构风格的一个典型应用。从其诞生之日开始，它就因其可扩展性和简单性受到越来越多的架构师和开发者们的青睐。一方面，随着云计算和移动计算的兴起，许多企业愿意在互联网上共享自己的数据、功能；另一方面，在企业中，RESTful API（也称RESTful Web服务）也逐渐超越SOAP成为实现SOA的重要手段之一。时至今日，RESTful架构风格已成为企业级服务的标配。REST即Representational State Transfer的缩写，可译为表现层状态转化”。REST最大的几个特点为：资源、统一接口、URI和无状态。1.1 RESTful架构风格的特点1.1.1 资源所谓资源，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。资源总要通过某种载体反应其内容，文本可以用txt格式表现，也可以用HTML格式、XML格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现；JSON是现在最常用的资源表示格式。结合我的开发实践，我对资源和数据理解如下：资源是以json(或其他Representation)为载体的、面向用户的一组数据集，资源对信息的表达倾向于概念模型中的数据：资源总是以某种Representation为载体显示的，即序列化的信息常用的Representation是json(推荐)或者xml（不推荐）等Represntation是REST架构的表现层相对而言，数据（尤其是数据库）是一种更加抽象的、对计算机更高效和友好的数据表现形式，更多的存在于逻辑模型中资源和数据关系如下：1.1.2 统一接口RESTful架构风格规定，数据的元操作，即CRUD(create, read, update和delete,即数据的增删查改)操作，分别对应于HTTP方法：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源，这样就统一了数据操作的接口，仅通过HTTP方法，就可以完成对数据的所有增删查改工作。即：GET（SELECT）：从服务器取出资源（一项或多项）。POST（CREATE）：在服务器新建一个资源。PUT（UPDATE）：在服务器更新资源（客户端提供完整资源数据）。PATCH（UPDATE）：在服务器更新资源（客户端提供需要修改的资源数据）。DELETE（DELETE）：从服务器删除资源。1.1.3 URI可以用一个URI（统一资源定位符）指向资源，即每个URI都对应一个特定的资源。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或识别符。一般的，每个资源至少有一个URI与之对应，最典型的URI即URL。1.1.4 无状态所谓无状态的，即所有的资源，都可以通过URI定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而改变。有状态和无状态的区别，举个简单的例子说明一下。如查询员工的工资，如果查询工资是需要登录系统，进入查询工资的页面，执行相关操作后，获取工资的多少，则这种情况是有状态的，因为查询工资的每一步操作都依赖于前一步操作，只要前置操作不成功，后续操作就无法执行；如果输入一个url即可得到指定员工的工资，则这种情况是无状态的，因为获取工资不依赖于其他资源或状态，且这种情况下，员工工资是一个资源，由一个url与之对应，可以通过HTTP中的GET方法得到资源，这是典型的RESTful风格。1.2 ROA、SOA、REST与RPCROA即Resource Oriented Architecture，RESTful架构风格的服务是围绕资源展开的，是典型的ROA架构（虽然“A”和“架构”存在重复，但说无妨），虽然RO