RESTfuls API

Web Service / API

Web interaction

1&2 用DNS协议去解析得到IP地址

3.TCP的三次握手与服务器建立连接

4.浏览器向服务器发送拼接好的报文

5.服务器收到报文处理请求，拼好的报文再发送给浏览器

1&2 用DNS协议去解析得到IP地址

ISP的DNS解析程序最终获得用户需要的IP地址。解析程序将此值返回至Web浏览器。DNS解析程序还会将amazon.com 的IP 地址缓存(存储)您指定的时长，以便它能够在下次有人浏览amazon.com 时更快地作出响应。

DNS(Domain Name System) 可以将域名和IP地址相互映射的一个分布式数据库，能够使人更方便的访问互联网。

3.TCP的三次握手与服务器建立连接

传输控制协议(Transmission Control Protocol,TCP).用于确保可靠的数据传输。TCP与IP一起使用，这两个协议经常被合称为 TCP/IP。 TCP三次握手的过程 (1)SYN:第一次握手由浏览器发起，告诉服务器我要发送请求; (2)SYN/ACK:第二次握手由服务器发起，告诉浏览器我准备接收了，你发送吧: (3)ACK:第三次握手由浏览器发起，告诉服务器,我马上发送，准备接收;

为什么需要三次握手,2次不行吗? 如果只有2次的话，B并不清楚A是否收到他发过去的信息。(A是web browser, B是web server)

4.浏览器向服务器发送拼接好的报文

客户端请求消息 客户端发送一个HTTP请求到服务器的请求消息包括以下格式:请求行(requestline)、请求头部(header)、空行和请求数据四个部分组成，下图给出了请求报文的一般格式。

5.服务器收到报文处理请求，拼好的报文再发送给浏览器

服务器响应消息 HTTP响应也由四个部分组成，分别是:状态行、消息报头空行和响应正文。

HTTP – reuqest & response 的例子

URI & 可寻址 每个资源至少一个 URI；系统应可寻址（能指到很多具体资源，而不是一个“大黑盒”入口）。

表示（Representation） 资源需要“长什么样”的数据（JSON/XML/HTML/CSV…），也能反向：客户端提交一个表示，服务器用它来创建/更新资源。

HTTP 方法 = 操作语义（CRUD 对应）

GET：读一个表示（只读）。
POST：由服务器分配 URI，创建/触发“有副作用”的动作。
PUT：客户端给出 URI，创建（若不存在）或整体替换（若已存在）。
PATCH：部分更新（只改某几项）。
DELETE：删除该资源。
还有 HEAD/OPTIONS（看元信息 / 看允许的方法）。

咖啡订单示例： POST /starbucks/orders （创建一张新订单，服务器告诉你新订单的 URI） GET /starbucks/orders/order?id=1234（读取 1234） PUT /starbucks/orders/order?id=1234（整体替换 1234） DELETE …id=1234（删除 1234）。

HTTP1.0

GET方法请求指定资源的表示。使用GET的请求应该只用于请求数据，而不应该包含数据。e.g. GET /index.html
HEAD方法请求资源的标头信息，并且这些标头与HTTP GET方法请求时返回的一致。该请求方法的一个使用场景是在下载一个大文件前先通过HEAD 请求读取其Content-Length标头的值获取文件的大小，而无需实际下载文件，以此可以节约带宽资源。e.g. HEAD /index.html
POST方法发送数据给服务器(是对服务器资源进行修改)。请求主体的类型由Content-Type标头指定。

HTTP

POST/test HTTP1.1
Host:foo.example
Content-Type:application/x-www-form-urlencoded
Content-Length:27

file1=value1&filed2=value2

POST/test HTTP1.1
Host:foo.example
Content-Type:application/x-www-form-urlencoded
Content-Length:27

file1=value1&filed2=value2

HTTP1.1 新增

PUT请求方法创建一个新的资源或用请求的有效载荷替换目标资源的表示（也是对服务器资源进行修改）。PUT与POST方法的区别是，PUT方法是幂等的:调用一次与连续调用多次效果是相同的(即没有副作用)，而连续调用多次相同的POST方法可能会有副作用比如多次提交同一订单。

HTTP

PUT/new.html HTTP/1.1
Host:example.com
Content-type:text/html
Content-length:16

<p>newfile</p>

PUT/new.html HTTP/1.1
Host:example.com
Content-type:text/html
Content-length:16

<p>newfile</p>

响应如果目标资源已经存在，并且依照请求中封装的表现形式成功进行了更新，那么，源服务器必须返回 200(OK)或 204(No Content)来表示请求成功完成。

HTTP

HTTP/1.1 201 Created
Content-Location:/new.html

HTTP/1.1 201 Created
Content-Location:/new.html

HTTP

HTTP/1.1 204 Not Content
Content-Location:/existing.html

HTTP/1.1 204 Not Content
Content-Location:/existing.html

DELETE 请求方法用于删除指定资源请求:

HTTP

DELETE/file.html HTTP/1.1
Host:example.com

DELETE/file.html HTTP/1.1
Host:example.com

响应： 如果DELETE方法执行成功，那么会有下面几种状态码

状态码202(Accepted)表示请求的操作可能会成功执行，但是尚未开始执行。状态码204(No Content)表示操作已执行，但是没有进一步的相关信息。状态码200(OK)表示操作已执行，并且响应中提供了相关状态的描述信息。

HTTP

HTTP/1.1 200 Ok
Date:Wed,21 Oct 2015 07:28:00 GMT

<html>
 <body>
 	<h1>DELETED</h1>
 </body>
</html>

HTTP/1.1 200 Ok
Date:Wed,21 Oct 2015 07:28:00 GMT

<html>
 <body>
 	<h1>DELETED</h1>
 </body>
</html>

CONNECT 方法可以开后与所青求资源之间的双向沟通的通道。它可以用来创建隧道(tunnel)

HTTP

CONNECT server.example.com:80 HTTP/1.1
Host:server.example.com:80
Proxy-Authorization:basic aGvsbG86d29ybGQ=

CONNECT server.example.com:80 HTTP/1.1
Host:server.example.com:80
Proxy-Authorization:basic aGvsbG86d29ybGQ=

OPTIONS请求给定的 URL 或服务器的允许通信选项。客户端可以用这个方法指定一个 URL,或者用星号(*)来指代整个服务器。

请求检测服务器所支持的请求方法要想知道一个服务器支持哪些请求方法，可以使用curl 命合行程序来发出 OPTIONS 请求: curl -XOPTlONS https://example.org -i

响应包含Allow标头值表明了服务器支持的所有HTTP方法

HTTP

HTTP/1.1 204 No Content
Allow:OPTIONS,GET,HEAD,POST
Cache-Control: max-age=604800
Date:Thu,13 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)

HTTP/1.1 204 No Content
Allow:OPTIONS,GET,HEAD,POST
Cache-Control: max-age=604800
Date:Thu,13 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)

TRACE 方法沿着通往目标资源的路径进行信息回环测试提供一个有用的调试机制。TRACE /index.html
PATCH 请求方法用于对资源进行部分修改。PATCH 请求是一组关于如何修改资源的指合，与 PUT 形成对比;后者是一个资源的完整表述

请求

HTTP

PATCH/file.txt HTTP/1.1
Host:www.example.com
Content-Type:application/example
If-Match:"e0023aa4e"
Content-Length:100

[描述变化情况]

PATCH/file.txt HTTP/1.1
Host:www.example.com
Content-Type:application/example
If-Match:"e0023aa4e"
Content-Length:100

[描述变化情况]

响应

HTTP

HTTP/1.1 204 No Content
Content-Location:/file.txt
ETag:"e0023aa4f"

HTTP/1.1 204 No Content
Content-Location:/file.txt
ETag:"e0023aa4f"

HTTP safe安全性

如果说一个HTTP方法是安全的，是指这是个不会修改服务器的数据的方法。也就是说，这是一个对服务器只读操作的方法。这些方法是安全的: GET，HEAD和OPTIONS。所有安全的方法都是幂等的，但所有非所有幂等方法都是安全的例如，PUT 和 DELETE 都是幂等的,但不是安全的。

Idempotent 幂等性

一个 HTTP 方法是幂等的，指的是同样的请求被执行一次与连续执行多次的效果是一样的,服务器的状态也是一样的。换句话说就是，幂等方法不应该具有副作用(统计用途除外)。在正确实现的条件下，GET，HEAD，PUT和DELETE等方法都是幂等的,而POST方法不是。所有的safe方法也都是幂等的。幂等性只与后端服务器的实际状态有关，而每一次请求接收到的状态码不一定相同。例如，第一次周用 DELETE 方法有可能返回200，但是后续的请求可能会返回404。

为什么重要：网络不可靠时，你才能安心重试：GET/PUT/DELETE 重试没副作用；POST 重试可能多下了几杯咖啡。

常见误用

用 GET 去删除/修改：错（不安全）。
在 URL 里写动作名：/getCustomer、/doSearch：错（RPC 风格，不 REST）。应当是“名词 + HTTP 动词”。

HTTP Response stauts code

状态码主要分为5大类

1xx:Informational提示信息，表示目前是办议处理的中间状态，还需要后续的操作;
2xx:Success成功，报文已经收到并被正确处理;
- 200 OK 是最常见的成功状态码，表示一切正常，服务器如客户端所期望的那样返回了处理结果，如果是非HEAD，请求通常在响应头后都会有 body数据。
- 204 No Content 是另一个很常见的成功状态码，它的含义与200 OK基本相同，但响应头后没有body数据。所以对于Web 服务器来说，正确地区分200和204是很必要的
- 206 Partial Content 是HTTP 分块下载或断点续传的基础, 在客户端发送范围请求、要求获取资源的部分数据时出现, 它与200一样，也是服务器成功处理了请求，但body里的数据不是资源的全部，而是其中一部分
3xx:Redirection 重定向,资源位置发生变动,需要客户端重新发送请求;
- 301Moved Permanently 永久重定向，含义是此次请求的资源已经不存在了，需要改用新的URI再次访问。
- 302Found 与301类似，曾经的描述短语是Moved Temporarily，俗称临时重定向，意思是请求的资源还在，但需要暂时用另一个URI 来访问。
- 304Not Modifed ** **是一个比较有意思的状态码，它用于If-Modifhed-Since等条件请求，表示资源未修改，用于缓存控制。它不具有通常的跳专含义，但可以理解成重定向已到缓存的文件
4xx:Client Error 客户端错误,请求报文有误,服务器无法处理;
- 400 Bad Request 是一个通用的错误码,表示请求报文有错误，但具体是数据格式错误误、缺少请求头还是URI超长它没有明确说，只是一个笼统的错误，客户端看到400只会是一头雾水、不知所措。所以，在形Web 应用时应当尽量避免给客户端返回400，而是要用其他更有明确含义的状态码。
- 403 Forbidden 实际上不是客户端的请求出错，而是表示服务器禁止访问资源。原因可能多种多样，例如信息敏感、法律禁止等，如果服务器友好一点，可以在body里详细说明拒绝请求的原因，不过现实中通常都是直接给一个闭门羹。
- 404 Not Found 最常看见也是最不愿意看到的一个状态码，它的原意是资源在本服务器上未找到所以无法提供给客户端。但现在已经被「用滥了」只要服务器不高兴就可以给出个404，而我们也无从得知后面到底是真的未找到，还是有什么别的原因，某种程度上它比403 还要合人讨厌。
5xx:Server Error 服务器错误，服务器在处理请求时内部发生了错误。
- 500 Internal Server Error与400类似,也是一个通用的错误码，服务器究竟发生了什么错误我们是不知道的。不过对于服务器来说这应该算是好事，通常不应该把服务器内部的详细信息，例如出错的医数调用栈告诉外界。虽然不利于调试，但能够防止黑客的窥探或者分析。
- 502 Bad Gateway 通常是服务器作为网关或者代理时返回的错误码，表示服务器自身工作正常,访问后端服务器时发生了错误，但具体的错误原因也是不知道的。
- 503 Service Unavailable 表示服务器当前很忙,暂时无法响应服务，我们上网时有时候遇到的「网络服务正忙,请稍后重试」的提示信息就是状态码 503。503是一个「临时」的状态很可能过几秒钟后服务器就不那么忙了，可以继续提供服务，所以503响应报文里通常还会有一个Retry-After 字段口指示客户端可以在多久以后再尝试发送请求。

URL – HTTP Scheme

URI/URL/URN URI是抽象的定义，不管用什么方法表示,只要能定位一个资源，就叫URI。具体分为:URL用地址定位& URN 用名称定位 ——就是资源地址（像“路怎么走”）

URl:Uniform Resourceldentifer 统一资源标志符

URI的最常见的形式是统一资源定位符（URI）被称作为Web地址比如： http://www.example.com:80/path/to/myfle.html?key1=value1&key2=value2#SomewhereInTheDocument
http:// 指代是何种协议 protocol,
www.example.com 网站域名 domain
:80然后是域名后面紧跟着的端口port :80它表示用于访问 Web 服务器上资源的技术”门”。
/path/to/myfile.html 路径path to the file，web服务器上的资源路径
?key1=value1&key2=value2 查询 parameters 是提供给 Web 服务器的额外参数。这些参数是用& 符号分隔的键/值对列表。
#SomewhereInTheDocument 片段Anchor 是资源本身的某一部分的一个锚点。锚点代表资源内的一种”书签”，它给予浏览器显示位于该”加书签”点的内容的指示。例如，在HTML文档上,浏览器将滚动到定义锚点的那个点上;在视频或音频文档上，浏览器将转到锚点代表的那个时间。

URL:Uniform Resource Locator 统一资源定位符

URN:UniformResource Name统一资源名称

Web的三个核心标准

Web资源的表达、Web资源的定位、Web资源传输

用超文本技术HTML来表达信息，以及建立信息与信息的链接。
用统一资源定位符URL来实现Web资源的精准定位。
用网络应用层协议HTTP来规范浏览器与Web服务器之间的通信过程。

SOAP vs REST

SOAP和REST是两种互联网数据交换机制。例如，假没您的内部账户系统与客户的账户系统共享数据，以自动执行开发票任务。这两个应用程序使用定义通信规则的 API 共享数据。SOAP和REST是两种不同的API设计方法。SOAP方法是高度结构化的，它使用可扩展标记语言XML 数据格式。REST更灵活，允许应用程序交换多种格式的数据。

它们都描述了有关应用程序如何发出、处理和响应来自其他应用程序的数据请求的规则和标准，它们都(可以)使用标准化互联网协议 HTTP 来交换信息它们都支持SSL/TLS 进行安全、加密的通信

SOAP：严格的 XML 信封 + WSDL 描述，能跑在多种传输上（HTTP/SMTP…），但重、要封包解包、移动端时代吃不消。
REST：一种架构风格（不是协议），直接借用 HTTP 的方法/状态码/内容协商，轻量灵活，常用 JSON 表示数据。

JSON 示例（看起来就清爽）： GET /stockquote/DIS 返回 {“ticker”:”DIS”,”price”:34.5}。客户端用 Accept: application/json 表示想要 JSON。

这门课的重点将会关注于RESTful API

REST

Resources 资源 — 是REST服务基本构建块

REST的名称”表现层状态转化”中，省略了主语。”表现层”其实指的是”资源”(Resources)的”表现层”。所谓”资源”，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、-张图片、一首歌曲、一种服务，总之就是-个具体的实在。你可以用一个URL(统一资源定位符)指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。所谓“上网”，就是与互联网上一系列的”资源”互动，调用它的URI。

把一切要操作/交流的对象都当成“资源”。resources 资源必须：可唯一识别、有至少一种表示、有属性（不止一个 ID）、可被寻址（有 URI）、可能有集合/关系（学生-课程-专业）。

Representation表现层

“资源”是一种信息实体，它可以有多种外在表现形式。我们把”资源”具体呈现出来的形式,叫做它的”表现层”(Representation)。比如，文本可以用txt格式表现,也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式;图片可以用JPG格式表现，也可以用PNG格式表现。

State Transfer状态转化

访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生”状态转化”(StateTransfer)。而这种转化是建立在表现层之上的，所以就是”表现层状态转化”。客户端用到的手段，只能是HTTP协议，比如，GET用来获取资源，POST用来更新建资源，PUT用来更资源，DELETE用来删除资源，PATCH用来更新资源

状态转移（Representational State Transfer & REST） 你通过链接（/students/1001）和操作（GET/DELETE…）在应用状态机里跳转——每一步服务器把下一个状态的表示传给你。

多种表示 同一个资源可以给你 JSON、XML、网页、CSV…两种常见做法：

不同 URL：/release_doc/104.en /104.es /104.fr（很“可寻址”）。
内容协商：同一个 URL + 请求头 Accept-Language / Accept。两种都对。

Rest的特点因此有

用明确的方法操作语义清晰的资源，来呈现不同的资源表现形式

资源:每一个URI都代表一种资源:
方法:客户端Client使用GET、POST、PUT、DELETE 等表示操作
方法操作资源:通过不同方法来操作资源，导致了资源不同的表现形式。
操作结果表现:资源的表现形式可以是JSON.XML或者HTML等
无状态:客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息。

RESTful Constraints——5+1 个架构约束

客户端-服务器分离/解耦(Client-Server)：界面/体验与业务/数据分开演进。收件人、发件人在技术，平台，编程语言方面相互独立
统一接口（Uniform Interface）：全网都用同样的 HTTP 语义来操作资源。API以完整且完全可用的标准格式返回数据
无状态(Statelessness)：每个请求独立自足，服务端不记会话状态（有登录也放客户端令牌里）。API独立于先前的请求完成每个新请求
可缓存(Caching)：合适地让响应被缓存，省流量提性能。所有的API都是可缓存的
分层系统(Layered System)：中间层/网关/负载均衡…对客户端是透明的。服务器可以有几个共同协作以完成客户端请求的中介体，但它们对客户端是不可见的。
按需编码（Code on demand (optional)）: 如果需要，API响应可以包含代码片段 满足前五条，就可以自称 RESTful。

Client-Server

在 RESTAPI设计中，客户端和服务器的应用程序必须彼此完全独立。客户端应用程序应该知道的唯一信息是所青求资源的URI:它不能以任何其他方式与服务器应用程序交互。同样，除了通过 HTTP 将客户端应用程序传递到所请求的数据外，服务器应用程序不应修改客户端应用程序。

Statelessness 无状态怎么理解

在 REST架构中，无状态指一种服务器独立于所有之前的请求完成每个客户端请求的通信方法。客户端可以以任意顺序请求资源，每个请求为无状态或与独立于其他青求。此RESTAPI设计约束意味着服务器每次可以完全识别和满足请求不允许服务器应用程序存储与客户端请求相关的任何数据。

HTTP 天生无状态；REST 要求服务器不保会话。
“那我登录呢？”——把会话放客户端（例如令牌），每个请求都自带认证信息，服务器仍然按独立请求处理。这样易水平扩展、易缓存。

Uniform Interface

统一接口施加了4个架构限制:

资源的标识。资源是任何可以的名的事物，比如用、评论等。REST整个都是围绕资源展开的，不像其它一些风格可能是以动词形式，REST里面的资源都是一些名词，不仅如此每个资源都可以被URI唯一的标识。

通过表述对资源执行操作。表述就是Representational，比如JSON、XML等。反过来理解，客户端不能直接操作(比如SQL)服务端资源，客户端只能通过表述(比如SON)来操作资源。

自描述的消息。每个请求或响应必须提供足够的信息让接受者理解,这些消息是指比如媒体类型、HTTP方法、是否缓存。

超媒体作为应用状态引擎。超媒体:带文字的链接，应用状态:一个网页;引擎:驱动、跳转，其实意思就是点击链接跳转另一个网页或者另一个JSON。

Caching

RESTful Web 服务支持缓存,缓存是指将一些响应存储在客户端或中间方上以提高服务器响应时间的流程。例如，访问某个网站,该网站的每个页面都包含通用的页眉和页脚图像。每次您访问新的网站页面时，服务器必须重新发送相同的图像。为了避免出现这种情况，客户端在首次响应后会缓存或存储这些图像，之后直接使用缓存中的图像。RESTful Web 服务通过使用自行定义为可缓存或不可缓存的API 响应来控制缓存。 ETag 是由Web 服务器分配给在URL中找到的特定版本资源的不透明标识符。如果该 URL的资源表示发生了变化，则会重新分配一个新的ETag。ETag类似于指纹，可以快速进行比较以确定资源的两种表示是否相同。

Layered System

客户端不应该关心请求经过了多少中间层，只需要关心请求的结果。架构的系统可以分为多个层次，每一层独立完成自己的任务。这样的架构结构使得系统更容易维护，并且允许独立替换不同层次。通过约束组件行为允许架构由分层组成，这样每个组件都不能”看到”超出它们与之交互的直接层。例如，数据库存储层可以独立于其他层，在不影响其他层的情况下进行替换或扩展。

Code on demand

在 REST架构风格中，服务器可以通过将软件编程代码传输到客户端暂时扩展或自定义客户端功能。例如，在任何网站上填写注册表单时，浏览器会立即高亮填不正确的电话号码。由于服务器发送的代码，浏览器可以实现这个功能。

RESTful API 优势

可扩展性
- 采用了RESTAPI 的系统可以高效扩展，因为 REST优化了客户端-服务器交互。无状态可减轻服务器负载，因为服务器不必保留过去的客户端请求信息。管理良好的缓存可部分或完全消除某些客户端-服务器交互。所有这些功能都支持可扩展性，并且不会导致通信瓶颈进而降低性能。
灵活性
- RESTful Web 服务支持客户端-服务器完全分离。该服务简化并分离了多种服务器组件，以便可以独立改进每个部分，平台或技术在服务器应用程序端更改，不会影响客户端应用程序。分层应用程序功能可进一步提升灵活性。例如，开服人员可以更改数据库层，而无需重新编写应用程序逻辑。
独立性
- REST API与所使用的技术相互独立。可以在不影响API设计的情况下以多种编程语言编写客户端和服务器应用程序。您也可以在不影响通信的情况下更改任何一端的基出技

COMP9321 – Data Services Engineering- Week 4

RESTfuls API

Web Service / API

Web interaction

1&2 用DNS协议去解析得到IP地址

3.TCP的三次握手与服务器建立连接

4.浏览器向服务器发送拼接好的报文

5.服务器收到报文处理请求，拼好的报文再发送给浏览器

HTTP – reuqest & response 的例子

HTTP1.0

HTTP1.1 新增

HTTP safe安全性

Idempotent 幂等性

HTTP Response stauts code

URL – HTTP Scheme

Web的三个核心标准

SOAP vs REST

REST

Resources 资源 — 是REST服务基本构建块

Representation表现层

State Transfer状态转化

Rest的特点因此有

RESTful Constraints——5+1 个架构约束

Client-Server

Statelessness 无状态怎么理解

Uniform Interface

Caching

Layered System

Code on demand

RESTful API 优势

评论

发表回复 取消回复

发表回复取消回复