【转载】RESTful 架构风格概述

本文转载自https://blog.igevin.info/posts/restful-architecture-in-general/

在移动互联网的大潮下，随着docker等技术的兴起，『微服务』的概念也愈来愈被你们接受并应用于实践，日益增多的web service逐渐统一于RESTful 架构风格，若是开发者对RESTful 架构风格不甚了解，则开发出的所谓RESTful API总会貌合神离，不够规范。

本文是我对RESTful 架构风格的一些理解，和你们分享一下，若是有问题，欢迎讨论。
Outline

1. RESTful架构风格
    1.1 RESTful架构风格的特色
        1.1.1 资源
        1.1.2 统一接口
        1.1.3 URI
        1.1.4 无状态
    1.2 ROA、SOA、REST与RPC
    1.3 本真REST与hybrid风格
2. 认证机制
    2.1 Basic Auth
    2.2 Token Auth
    2.3 OAuth
3. 总结

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架构的表现层

相对而言，数据（尤为是数据库）是一种更加抽象的、对计算机更高效和友好的数据表现形式，更多的存在于逻辑模型中

资源和数据关系以下：

resource vs data

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风格。

state

stateless

1.2 ROA、SOA、REST与RPC

ROA即Resource Oriented Architecture，RESTful 架构风格的服务是围绕资源展开的，是典型的ROA架构（虽然“A”和“架构”存在重复，但说无妨），虽然ROA与SOA并不冲突，甚至把ROA看作SOA的一种也何尝不可，但因为RPC也是SOA，比较久远一点点论文、博客或图书也常把SOA与RPC混在一块儿讨论，所以，RESTful 架构风格的服务一般被称之为ROA架构，不多说起SOA架构，以便更加显式的与RPC区分。

RPC风格曾是Web Service的主流，最初是基于XML-RPC协议（一个远程过程调用（remote procedure call，RPC)的分布式计算协议），后来渐渐被SOAP协议（简单对象访问协议（Simple Object Access Protocol））取代；RPC风格的服务，不只能够用HTTP，还能够用TCP或其余通讯协议。但RPC风格的服务，受开发服务采用语言的束缚比较大，如.NET框架中，开发web service的传统方式是使用WCF，基于WCF开发的服务即RPC风格的服务，使用该服务的客户端一般要用C#来实现，若是使用python或其余语言，很难实现能够直接与服务通讯客户端；进入移动互联网时代后，RPC风格的服务很难在移动终端使用，而RESTful风格的服务，因为能够直接以json或xml为载体承载数据，以HTTP方法为统一接口完成数据操做，客户端的开发不依赖于服务实现的技术，移动终端也能够轻松使用服务，这也加重了REST取代RPC成为web service的主导。

RPC与RESTful的区别以下面两个图所示：

blog-post-REST-vs-RPC1

blog-post-REST-vs-RPC2

1.3 本真REST与hybrid风格

一般开发者作服务相关的客户端开发时，使用的所谓RESTful服务，基本可分为本真REST和hybrid风格两类。本真REST即我上文阐述的RESTful架构风格，具备上述的4个特色，是真正意义上的RESTful风格；而hybrid风格，只是借鉴了RESTful的一些优势，具备一部分RESTful的特色，但对外依然宣称是RESTful风格的服务。（窃觉得，正是因为hybrid风格服务混淆了RESTful的概念，才在RESTful架构风格提出了本真REST的概念，觉得了划分界限 :P）

hybrid风格的最主流的用法是，使用GET方法获取资源，用POST方法实现资源的建立、修改和删除。hybrid风格之因此存在，据我了解有两种来源：一种状况是由于，某些开发者并无真正理解何为RESTful架构风格，致使开发的服务貌合神离；而主流的缘由是因为历史包袱 —— 服务原本是RPC风格的，因为上文提到的RPC的劣势及RESTful的优点，开发者在RPC风格的服务上又包装了一层RESTful的外壳，一般这层外壳只为获取资源服务，所以会按RESTful风格实现GET方法，若是客户端提出一些简单的建立、修改或删除数据的需求，则经过HTTP协议中最经常使用的POST方法实现相应功能。

所以，开发RESTful 服务，若是没有历史包袱，不建议使用hybrid风格。

2. 认证机制

stateless-auth

因为RESTful风格的服务是无状态的，认证机制尤其重要。例如上文提到的员工工资，这应该是一个隐私资源，只有员工本人或其余少数有权限的人有资格看到，若是不经过权限认证机制对资源作一层限制，那么全部资源都以公开方式暴露出来，这是不合理的，也是很危险的。

认证机制解决的问题是，肯定访问资源的用户是谁；权限机制解决的问题是，肯定用户是否被许可以使用、修改、删除或建立资源。权限机制一般与服务的业务逻辑绑定，所以权限机制须要在每一个系统内部定制，而认证机制基本上是通用的，经常使用的认证机制包括 session auth(即经过用户名密码登陆)，basic auth，token auth和OAuth，服务开发中经常使用的认证机制为后三者。

2.1 Basic Auth

HTTP Basic authentication (BA) implementation is the simplest technique for enforcing access controls to web resources because it doesn't require cookies, session identifier and login pages. Rather, HTTP Basic authentication uses static, standard fields in the HTTP header which means that no handshakes have to be done in anticipation.

Visit Wikipedia To Read More

简言之，Basic Auth是配合RESTful API 使用的最简单的认证方式，只需提供用户名密码便可，但因为有把用户名密码暴露给第三方客户端的风险，在生产环境下被使用的愈来愈少。所以，在开发对外开放的RESTful API时，尽可能避免采用Basic Auth

2.2 Token Auth

Token Auth并不经常使用，它与Basic Auth的区别是，不将用户名和密码发送给服务器作用户认证，而是向服务器发送一个事先在服务器端生成的token来作认证。所以Token Auth要求服务器端要具有一套完整的Token建立和管理机制，该机制的实现会增长大量且非必须的服务器端开发工做，也不见得这套机制足够安全和通用，所以Token Auth用的并很少。

本文不在展开介绍Token Auth，我我的对这套机制也了解有限，有兴趣了解这套机制的同窗不妨从Stack Overflow上的这篇讨论入手。

2.3 OAuth

OAuth is an open standard for authorization. OAuth provides client applications a 'secure delegated access' to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The client then uses the access token to access the protected resources hosted by the resource server. OAuth is commonly used as a way for Internet users to log into third party websites using their Microsoft, Google, Facebook or Twitter accounts without exposing their password.

OAuth is a service that is complementary to and distinct from OpenID. OAuth is also distinct from OATH, which is a reference architecture for authentication, not a standard for authorization. However, OAuth is directly related to OpenID Connect (OIDC) since OIDC is an authentication layer built on top of OAuth 2.0.

Visit Wikipedia To Read More

OAuth（开放受权）是一个开放的受权标准，容许用户让第三方应用访问该用户在某一web服务上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。

OAuth容许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每个令牌受权一个特定的第三方系统（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth让用户能够受权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非全部内容。

正是因为OAUTH的严谨性和安全性，如今OAUTH已成为RESTful架构风格中最经常使用的认证机制，和RESTful架构风格一块儿，成为企业级服务的标配。

目前OAuth已经从OAuth1.0发展到OAuth2.0，但这两者并不是平滑过渡升级，OAuth2.0在保证安全性的前提下大大减小了客户端开发的复杂性，所以，Gevin建议在实战应用中采用OAuth2.0认证机制。

如今网上关于OAuth的资料很是丰富，也有大量开源的第三方库实现了OAuth机制，不熟悉OAuth的同窗从OAuth官网入手便可。

3. 总结

本真REST + OAuth是RESTful 是微服务的标配
Basic Auth只在开发环境中使用
设计合理的资源
用正确的HTTP方法对数据发正确的请求