RESTful Web 服务:教程

脑图


RESTful

 

目录


  1. 什么是RESTful

  2. HTTP方法

  3. 清晰的RESTful API

  4. RESTful 消息

  5. RESTful URI

  6. RESTful 会话

趁着 REST 成为多数 Web 和 Mobile
应用的默认选项,势必要对她的基本原理有所了解。

什么是RESTful


  • REST是相同种基于web标准软件架构标准
  • 于这专业中,把方方面面调用或请的对象,都算得资源,所以,其基本思想,一切皆资源
  • 客户端和服务端之间以HTTP处理数量通信
  • REST架构中,服务端提供对资源的造访,而客户端,访问并显现资源
  • 据此,REST架构中,主要参与者,就是客户端与服务端
  • 服务端,负责在全套对资源的操作,这些操作会被封装成一个RESTful
    API,用于客户端请求
  • URIs是REST架构中的大局ID标识

于其提出十基本上年晚的今日,REST 已经化为极端要的 Web
应用技术有。随着所有技术为 API
方向前行,它的最主要有或持续高效地增强。每门主要编程语言现在既包含构建
RESTful Web 服务之框架。同样地,Web 开发者和绑架构师对 REST 和 RESTful
服务产生一个清晰的接头是深重大之。这首教程解释了 REST
架构,然后研究利用它构建通用地基于API的任务之细节。

HTTP 方法


  • GET 提供资源的就念访问
  • PUT 创建一个初资源
  • DELETE 用于移除一个资源
  • POST 更新现有资源还是创造新资源
  • OPTIONS 用于取该资源所支持之操作

什么是 REST

REST 代表表述性状态转移(representational state
transfer),它是一模一样种植网络化超媒体应用之架风格。它根本是用来构建轻量级的、可保护的、可伸缩的
Web 服务。基于 REST 的服务为叫作 RESTful 服务。REST
不依赖让外协议,但是几乎每个 RESTful 服务用 HTTP 作为底层协议。

RESTful 使用HTTP
post(创建、更新)数据、读取数据、删除数据。使用HTTP实现CRUD(创建、读取、更新、删除)操作。

清晰的RESTful API


RESTful API

假设图,操作类型受到,只念指无见面改资源,幂等靠多次推行有的影响及跟第一不行实践有的影响是相同的,N/A在表中,可掌握呢
/ 即划掉此格,不用理会此格

这边顺便解释一个概念:幂等函数,或掩盖等办法,是依好利用相同参数还执行,并会取得一致结果的函数。

REST服务器对资源的表现形式应该是包容的,即以什么格式传递数据,应该由客户端来指定:有客户端要xml而有些客户端要json

RESTful 服务特色:

每个系统都动资源。这些资源得以是图,视频文件,网页,商业信息,或者以冲计算机的系统面临得以给代表的任何事物。服务之目的是提供一个窗口为客户端以便客户端能访问这些资源。服务架构师和开发人员想只要这些服务转移得易让贯彻、维护、扩展、伸缩。RESTful
架构允许这些,甚至又多。一般的话,RESTful
服务应该有下的习性与特点,也便是自己要是详细描述的情节:

  • 模型表示(Representations)
  • 消息(Messages)
  • URIs
  • 平等接口(Uniform interface)
  • (无状态)Stateless
  • 资源间的链接(Links between resources)
  • 缓存(Caching)

RESTful消息


当REST服务中,HTTP请求与应就是作为消息传递的技巧
一个REST消息包含消息数据与首家数据(为叙数据的数量)

  • 请求

HTTP Request

Verb(动作) 表明HTTP方法,如GET、POST等
URI 表示服务器上资源的统一资源标识符
HTTP VERSION (http版本) 如 http v1.1
请求头,包含HTTP请求消息的元数据,它是键值对(key-value),比如客户端类型
请求体,消息内容和要求的REST服务器返回资源的表示形式
  • 响应

HTTP Response

Response Code(状态/响应码),表明请求资源的服务器状态,比如404 500等
HTTP VERSION http版本
响应头 返回响应的元数据 如服务器类型等,也是键值对
响应体 以客户端想要的资源表现形式返回资源

模型表示(Representations)

RESTful
服务的刀口以资源上及怎么提供对资源的访。资源充分轻吃看与OOP中之靶子同。一个资源会由其他资源结合。当设计一个体系的上,第一件如举行的事情是概念资源同控制资源中的涉嫌。这发生接触像计划数据库的首先步。定义实体和涉及。

只要我们定义了资源,接下我们用找到同样栽用于在系统面临意味这些资源的艺术。你得应用外格式来代表资源。REST
对这并未限定。

譬如,根据你的需要,你得操纵以 JSON 或者 XML。如果你在构建 Web
服务,此服务用于 Web 页面中之 AJAX 调用,那 JSON 是格外好地摘。 XML
可以就此来表示比较复杂的资源。例如一个于喻为“Person”的资源得以象征如下:

RESTful API


RESTful web 服务的URI(统一资源标识符)定义规则

  • 见名知意
  • 避下空格与特殊字符,一般以下划线(_)或者字符(-)代替
  • 采用小写字母,URI本身是休分轻重缓急写的
  • 保为后相当,Web服务是均等栽公共服务,URI一旦公开以后,应该一味可用,尽管要更新URI,那吧急需使用HTTP
    300 重定向一直的URI到新的URI
  • 使用HTTP Verb

Verb规则

  • GET是一味读且安全的
  • PUT和DELETE是幂等的
  • PUT和POST操作几乎一样,区别在于PUT幂等,而POST不幂等

列表1:资源的JSON 表示。

{
    "ID": "1",
    "Name": "M Vaqqas",
    "Email": "m.vaqqas@gmail.com",
    "Country": "India"
}

RESTful 会话


RESTful基给HTTP,是凭状态的,想使维持会话,则客户端传递会说话标识符,服务端保存会说话标识符。就如Session和Cookie。

随便状态的优势:

  • Web服务好单独对待每个请求方法
  • Web服务不待维护客户端先前之互
  • HTTP本身就是是一个无论是状态协议,所以RESTful Web服务而及HTTP协议无缝协作

列表2:资源的XML 表示。

<Person>
    <ID>1</ID>
    <Name>M Vaqqas</Name>
    <Email>m.vaqqas@gmail.com</Email>
    <Country>India</Country>
</Person>

实质上,你可采用持续一种之格式并且决定以中哪一样栽用于因让客户端类型或一些请参数的应。无论以谁格式,好之模型表示(representation
)应该具备以下明显的特征:

  • 客户端和服务端应该会知道这种模型表示(representation )的格式。
  • 模型表示(representation
    )应该力所能及完整的表示资源。如果急需代表有资源,然后您用考虑将资源分解成子资源。分割好资源及再也有些的资源一样允许你传递更有些的见。较小的模型表示(representation)意味着又不见的时光来创造和传导。这也意味着又快之劳务。
  • 模型表示(representation)应该力所能及互为链接资源。可以经过轮换 URI
    或者是绝无仅有 ID。

RESTful 客户端缓存


当得到一个资源的时候,客户端应根据服务器返回的应头中所指定的法子,以控制是否缓存资源,或者坐何种措施缓存资源。

一个响应头可能带有的始末:

  • Date 创建资源的日期及日
  • Last Modified 最后修改资源的日期以及岁月
  • Cache-Control 控制缓存的要紧头信息
  • Expires 缓存到期的日子与日
  • Age 从服务器获取资源不断的秒数

Cache-Control的取值:

  • Public 表示该资源而由于其他组件缓存
  • Private 代表该资源只能由客户端与服务器缓存,没有中介得以缓存
  • No-cache/no-store 代表该资源不足缓存
  • Max-age
    代表该资源在max-age指定的秒数内中,之后客户端必须发起另一个请求
  • Must-revalidate 表明要max-age已经过去了,服务器如果再验证资源

消息(Messages)

客户端和服务端经由消息相互联系。客户端发送请求到服务器,服务器使用应答复。除了实际的数目,这些信吗隐含部分有关消息的首先数据。对于规划
RESTful 服务了解 HTTP 1.1的恳求格式和应格式是可怜重点之。

RESTful web服务安全性


  1. 证实来自客户端的富有输入,这可避免注入攻击。
  2. 用会话机制,对客户端此次请求进行权力认证。
  3. URL应避免敏感数据。
  4. 客观使用HTTP Verb,比如GET方法,不该力所能及去数据。
  5. 验证XML/JSON数据是否合法正常
  6. 成立正确的运用HTTP错误信息,比如403、500齐

HTTP常见状态码:

状态码

HTTP 请求

希冀1丁形了HTTP请求格式。

结语


RESTful是一个web服务之架正式,后端开发人员可以按此专业来促成API,而终端开发人员,同样好据此这标准来行使API。
业内的留存,就是以统一两者的预定,就好比一个接口,不论你用json返回数据还是xml返回数据,它都不曾一定之是非,只要开发组的成员约定好,同时返回两栽格式为实施(RESTful的思考,也是这样)
一个宽广使用的标准,可以减掉开发者之间的交流基金,也得被部分初入职的职工能又快适应项目。

本文来源半醒的狐狸博客

希冀1:HTTP 请求格式

<VERB> GET, PUT, POST, DELETE, OPTIONS等等 HTTP 方法的同栽。

<URI> 资源的URI。操作以在此 URI 上推行。

<HTTP Version> HTTP 版本,通常是“HTTP v1.1”。

<Request Header> 包含 header
键值对聚集的头版数据。这些设置包含消息的消息以及发送者像客户端的路,客户端支持的格式,消息体的格式类型,响应的缓存设置,和许多信。

<Request Body> 是实际的信内容。在 RESTful
服务被,这就算是信息受到资源表示的职务。

在 HTML 消息中没有签及标识符号区块的启幕要终止。

列表三凡简简单单的 POST 请求消息,这个请想要插入一漫长新的 Person 资源。

列表3:简单 POST 请求

POST http://MyService/Person/
Host: MyService
Content-Type: text/xml; charset=utf-8
Content-Length: 123
<?xml version="1.0" encoding="utf-8"?>
<Person>
  <ID>1</ID>
  <Name>M Vaqqas</Name>
  <Email>m.vaqqas@gmail.com</Email>
  <Country>India</Country>
</Person>

列表4:GET 请求

GET http://www.w3.org/Protocols/rfc2616/rfc2616.html HTTP/1.1
Host: www.w3.org
Accept: text/html,application/xhtml+xml,application/xml; …
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 …
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,hi;q=0.6

HTTP Response

祈求2显示了 HTTP 响应的格式:

贪图2:HTTP 响应格式。

服务器返回 <response code>,<response
code>包含呼吁的状态。<response
code>通常是三号数字的HTTP状态码(3-digit HTTP status
code)。

<Response Header> 包含关于响应消息的首先数据以及装置。

<Response Body> 包含如果请成功的模型表示(representation)。

列表5凡自个儿从清单三的要被落的真实性响应。

列表5:真实的 GET 请求的响应。

HTTP/1.1 200 OK
Date: Sat, 23 Aug 2014 18:31:04 GMT
Server: Apache/2
Last-Modified: Wed, 01 Sep 2004 13:24:52 GMT
Accept-Ranges: bytes
Content-Length: 32859
Cache-Control: max-age=21600, must-revalidate
Expires: Sun, 24 Aug 2014 00:31:04 GMT
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns='http://www.w3.org/1999/xhtml'>
<head><title>Hypertext Transfer Protocol -- HTTP/1.1</title></head>
<body>
...

应码 200 OK
表示一切正常,并且消息体包含我求的实用的模型表示(representation)。在是例子中,模型表示(representation)是
HTML 文档,HTML 文档是经过当响应头被的 Content-Type
声明地。在斯信息备受的 header
是不解自明地,但是自将会晤在交接下去的章中讨论他们受的一部分。这有许多别样属性。你得运用让Fiddle的免费工具抓取调试这些HTTP请求与应。

资源一定

REST 要求每个资源最少发生一个 URI。 RESTful
服务使人类可读的URIs层级目录来恒定资源。URI
要举行的劳作是概念一个资源要资源集。实际的操作由 HTTP 动作决定。URI
应该无其余关于处理与动作之情。这使我们会调用相同之 URI 使用不同之
HTTP 动词来执行不同的操作。

倘若我们发出一个 person 的数据库并且我们想通过服务器暴露于外部。Person
资源可以像下这样叫一定及:

http://MyService/Persons/1

这URL遵循格式:Protocol://ServiceName/ResourceType/ResourceID

对于构建优良的 URIs 这生头重要之引进:

  • 用复数名词命名你的资源。
  • 避使制造混乱的空格。使用_或者-代替。
  • URI
    不分轻重缓急写。为了重新清我用驼峰写法。你为堪下任何大写的URIs。
  • 君吧会发出若自己之约定,但是倘若在整服务保持一致。确保您的客户端都晓得这个约定。你的客户端
    URIs 程序构建以再次简短而她了解你以的资源层级与URI约定。
  • 好的 URI 是勿会见转的。再决定服务的 URIs
    之前要先期考虑思考。如果你用转移资源的原则性,不要放弃老的
    URI。如果请来自镇的 URI,使用状态码300重复定向客户端到新的location。
  • 免用动词命名你的资源直到你的资源是一个实际上地操作还是过程。动词更加契合操作的命名。例如,RESTful
    服务不应当产生 http://MyService/FetcthPerson/1
    或 http://MyService/DeletePerson?id=1
    类似的 URI。

URI中之询问参数

眼前的URI是为此查询参数帮助构建的。

http://MyService/Persons?id=1

询问参数方法运行良好而 REST
不会见拦你下查询参数。然而,这种方法发生一些劣势:

  • 多了复杂,降低了可读性。如果您以更多的参数问题会见愈发明确。
  • 比如Google这样的检索引擎爬网程序及索引器忽略uri查询参数。如果你正在进展Web开发,这是您的Web服务有怪怪之劣势,导致搜索引擎屏蔽。

询问参数的主干目的是提供参数为要之多少项的操作。例如,如果您想只要模型表示(presentation)格式由客户端决定,你可由此参数实现像下这样。

http://MyService/Persons/1?format=xml&encoding=UTF8

http://MyService/Persons/1?format=json&encoding=UTF8

带有format和encoding参数的父子层级URI看上去逻辑上无得法因为其并未这种涉及。

http://MyService/Persons/1/json/UTF8

询问参数为同意可选参数。在URI中显是无可能的。你只有应该在供参数值给处理过程的时节用。

合并接口

RESTful应该发生联合接口。HTTP 1.1
提供了千篇一律多级措施,被称为动作。在当时中比较根本之动作是:

图片 1

康宁之操作是凭借对原资源价值不会见起震慑之操作。列如,数学上之操作除以1即便是安的操作,因为随便多少次用1除了一个往往,原始数值都非会见改变。幂等操作是据无多少次施行都叫来一致结果的操作。例如,数学及之就以0就是幂等的,因为随便计算小坏结果尚且是零散,结果还是同样的。类似的,一个安康之HTTP方法不见面要服务器上之资源发生变化。一个幂等的HTTP方法无论执行多少次都见面生一样的应。把方分类成平安暨幂等的好使客户端在未安定的Web环境受到又接触相同之恳求的结果变得又可预测。

每当 Web 上 GET 可能是最风靡的法子。它用来获得资源。

HEAD
仅返回响应头和拖欠的响应体。这个点子可以用当您莫需全方位底资源模型表示(representation)的时段。例如,HEAD
可以快检测服务器上之资源是否在。

OPTIONS 用于取资源允许的操作。例如,思考下面的求:

OPTIONS http://MyService/Persons/1 HTTP/1.1
HOST: MyService

于服务证后要返回下内容:

200 OK
Allow: HEAD, GET, PUT

仲实行包含客户端可采用的方。

若应该一味出于它们的实际意义使用这些主意。例如:绝不要下 GET
在服务器上创设或者去资源。如果你没这样做,将会见干扰你的客户端导致她们做出意想不到之操作。举例说明,然我们着想下的乞求:

GET http://MyService/DeletePersons/1 HTTP/1.1
HOST: MyService

基于 HTTP 1.1 规范,GET
请求的目的是由服务器获取资源。但是它们特别容易实现一个刨除 Person
的乞求。这个要或运行的要命过硬,但是及时不是RESTful 设计。换言之,使用
DELETE 方法来删除资源像下这样:

DELETE http://MyService/Persons/1 HTTP/1.1
HOST: MyService

REST 建议统一接口,HTTP
提供了联合接口。然而,这是因为劳务架构师和开发人员保持它的联合。

PUT 和 POST 的区别

对此这有限个艺术本身提供了几同一之粗略描述。这半独方法困扰着诸多开发人员。所以吃咱们单独地谈论他们。

PUT 和 POST 的首要不同在 PUT 是幂等的,而 POST 不是。

另外一个异,使用 PUT 你要定义资源整体的
URI。这代表客户端能组织资源的URI哪怕资源不存在为服务器上。客户端选择资源唯一的讳或者
ID 是可能的。就如于服务器上创办一个用户要客户端选择用户
ID。如果客户端不克猜出资源总体的URI,你为难,只能动用 POST。

图片 2

挺显眼,PUT
请求不会见窜要创超过一个资源,无论触发多少次(如果URI相同)。当资源是时时
PUT 和 POST 是无分之,都是翻新就是资源。第三只请求(POST http://MyService/Persons/)会在每次触发都创资源。许多开发人员认为
REST 不同意 POST 被用来创新操作。然而,REST 并无这样的限定。

无状态

RESTful
服务是管状态的以不会见呢任何客户端保持状态。一个央不应当乘过去的求,服务相比每个请求都是独的。HTTP
是管状态协议的计划,你要做一些格外的业务实现状态服务。使用时之技艺真正坏易实现状态服务。我们用了解的理解无状态及发生状态统筹以便我们避免误解。

无论状态统筹像这么:

Request1: GET http://MyService/Persons/1
HTTP/1.1

Request2: GET http://MyService/Persons/2
HTTP/1.1

每个请求都能够吃单独对待。

发状态统筹,像这么:

Request1: GET http://MyService/Persons/1
HTTP/1.1

Request2: GET http://MyService/NextPerson
HTTP/1.1

为了处理第二个请求,服务器需要记住客户端最后收获之
PersonID。换句话说,服务器需要记住当前状态————否则要2无法处理。设计而的服务之法门是一个伸手绝不要涉及前一个央。无状态服务又易集群,更易保障,更爱伸缩。这样的服务提供了再次好的应时间,因为她能好的载荷均衡。

资源之间的链接

资源模型表示(representation )可以分包其他资源的链接就是像 HTML
页面包含到其它页面的链接一样。被劳务返回的模型表示(representations
)应该能让处理流就如网站的景况亦然。当访问网站的时刻,首先是索引页面,单击其中的一个链接跳反至另外一个页面等等。

让咱们着想下客户端请求一个暗含众多任何资源的资源。替代输入有资源,你或许会见列出资源的链接。

诸如,如果多单Person是Club的一模一样片,那么Club能如列表6被千篇一律表示。

列表6:Club

<Club>        
    <Name>Authors Club</Name>
    <Persons>
        <Person>
            <Name>M. Vaqqas</Name>
            <URI>http://MyService/Persons/1</URI>
        </Person>
        <Person>
            <Name>S. Allamaraju</Name>
            <URI>http://MyService/Persons/12</URI>
        </Person>
    </Persons>
</Club> 

缓存

缓存是存贮生成结果的定义,使用存储结果替代在快之明天还的请生成的结果。缓存可以在客户端、服务端或者他们中间的另组件上得,比如代理服务器。缓存是升格服务器性能的异常棒的措施。但万一无妥善处理,会招客户端采用失效的结果。

缓存可以由下的HTTP头控制:

图片 3

这些头部的价好组合起来用在Cache-Control指令中来检查缓存结果是否可行。最通用的用于Cache-Control的通令如下:

图片 4

劳动决定这些头与指令的价值是因资源的特色。

文档化 RESTful 服务

RESTful
服务不必包含用于扶持客户端发现它的文档。因为URIs、链接、统一接口,在运转时最好容易发现
RESTful
服务。客户端只需要简单地了解服务之底蕴地址,并且由这个地方客户端通过遍历资源正在用的链接就是能发现服务。OPTION
方法会吃有效地用当意识服务的处理过程中。

立不表示 RESTful
服务一点为无欲文档化。没有理由未文档化你的劳动。你应有为开发人员和客户端文档化每个资源同URI。你可以就此另外格式构建而的文档,但是她应有包含足够关于资源、URIs、可用方法的音讯,和其他需要拜访你的劳动以的信息。下面的
table 是我之 MyService 的略文档。这个简单少小之文档包含了 MyService
的诸面以足够开发一个客户端。

Service Name:MyService

Address: http://MyService/

图片 5

若为可文档化每个资源的模型表示(representations
)并且提供部分大概的模型表示(representations )。

结论

支付轻量级的 Web 服务 REST 是极其好的法门,容易实现,维护、暴露开放。HTTP
提供了卓越之接口来落实 RESTful
服务,比如统一接口及缓存。然而,那如开发人员正确地实现和应用这些特征。如果我们对基础来矣不利地解,那么用现有的技能仍Python、.net、java实现REST服务是那个盛之。我期待就首文章吧公起来开而协调的RESTful服务提供了足足的音讯。

参考

http://rest.elkstein.org/2008/02/what-is-rest.html

http://www.drdobbs.com/web-development/restful-web-services-a-tutorial/240169069

https://github.com/wanbei/blog/blob/master/html/restful-web-services.md

RESTJavaScriptRESTful

 

127

图片 6

图片 7

图片 8

图片 9

图片 10

收藏

分享

 

举报

文章于以下专栏收录

  • 图片 11
    FE-player

    前者玩家

    登专栏

6 条评论

形容下而的评论…

 

 

取消

评论

图片 12

于洋

发现作者就首稿子与本身之博文 『RESTful
架构风格概述』互补,把自身那篇里面没详细阐述的始末称的再度了解,我那么篇相对本文普及了重复多系知识。

http://blog.igevin.info/posts/restful-architecture-in-general/

1 赞

1 年前

举报

图片 13

张卓

图1 图2 都不曾图?

0 赞

1 年前

举报

图片 14

炊夜冷面

mark一下,谢谢分享

0 赞

1 年前

举报

图片 15

Crzidea

推荐一个方可自动生成RESTful API的仓库,功能很强劲:https://github.com/Meituan-Dianping/koa-restql

0 赞

1 年前

举报

图片 16

Eric
Bao

谢谢分享

0 赞

1 年前

举报

图片 17

随心泡面

mark mark

1 赞

8 个月前

举报

引进阅读

  • 图片 18
    锅包肉(yòu)正传
    东北在某种程度上,活在众人的设想着。饱妹来到北京从此,每天只要都领各种对东北话题的咨…查看全文

    福桃九分饱
    22 天前

    编辑精选

  • 图片 19
    袁牧:共享单车和城市规划
    共享单车都逐步成为公众出行的常见交通器,而那些五颜六色霸占街头的共享单车似乎尚于未停…查看全文

    清华同衡规划院
    1 天前

    编制精选发表于
    筹论衡

  • 图片 20
    于阿里早两年入场的京东叮咚,在国智能音箱的路上还获了啊
    | WARE 2017 人物专访
    阿里若生产智能音箱的音讯,就像相同枚重磅炸弹相同扔在了媒体圈。而即使于 7
    月 5 日阿里发布会…查看全文

    炫姐姐
    1 个月前

    编精选发表于 深圳湾 |
    shenzhenware

  • 图片 21
    搭建儿童之社会能力,离不起来家长的脚手架(2)
    (本文是7月20日当微信公众号:爱贝睿时间的讲座文稿第二部分)在前文(1)部分被说到,家长…查看全文

    刘建鸿
    6 天前

    编制精选

相关文章

网站地图xml地图