什么是RESTful编程？

什么是RESTful编程？

一种名为REST（Representational State Transfer）的架构风格主张web applications应该像最初设想的那样使用HTTP 。 Lookups应该使用GET请求。 PUT, POST, and DELETE请求应分别用于突变，创build和删除 。

REST支持者倾向于倾向于URLs ，例如 

 http://myserver.com/catalog/item/1729

但REST架构不需要这些“漂亮的url”。 带有参数的GET请求 

 http://myserver.com/catalog?item=1729

每一点都是RESTful。

请记住GET请求不应该用于更新信息。 例如，将一个项目添加到购物车的GET请求 

 http://myserver.com/addToCart?cart=314159&item=1729

将不合适。 GET请求应该是幂等的 。 也就是说，两次发出请求应该与发出一次没有区别。 这就是请求可caching的原因。 一个“添加到购物车”的请求是不幂等的 – 发出两次将该物品的两个副本添加到购物车。 在这种情况下，POST请求显然是合适的。 因此，即使是REST风格的Web应用程序也需要POST请求的份额。

这是来自Core JavaServer faces Book by David M. Geary

REST是Web的基础架构原则。 令人惊讶的事情是，客户端（浏览器）和服务器可以以复杂的方式进行交互，而客户端事先不了解服务器及其托pipe的资源。 关键的约束是服务器和客户端必须同意使用的媒体 ，在networking的情况下是HTML 。

遵循REST原则的API不要求客户端知道关于API结构的任何信息。 相反，服务器需要提供客户端与服务交互所需的任何信息。 HTML表单就是这样一个例子：服务器指定资源的位置和必填字段。 浏览器事先不知道提交信息的位置，也不知道提交什么信息。 这两种forms的信息完全由服务器提供。 （这个原则被称为HATEOAS ：超媒体作为申请状态的引擎 。）

那么，这是如何适用于HTTP的 ，怎样才能在实践中实现呢？ HTTP面向动词和资源。 主stream使用的两个动词是GET和POST，我想每个人都会认识。 但是，HTTP标准定义了其他几个如PUT和DELETE。 然后根据服务器提供的指令将这些动词应用于资源。

例如，让我们想象一下，我们有一个由Web服务pipe理的用户数据库。 我们的服务使用基于JSON的定制超媒体，为此我们分配了mimetype application / json + userdb （可能还有一个application / xml + userdb和application / whatever + userdb–可能支持多种媒体types）。 客户端和服务器都已经被编程来了解这种格式，但他们彼此之间并不知情。 正如Roy Fielding所指出的那样：

REST API应该花费几乎所有的描述性努力来定义用于表示资源和驱动应用程序状态的媒体types，或者为现有标准媒体types定义扩展关系名称和/或启用超文本的标记。

对基本资源的请求可能会返回如下所示的内容：

请求 

 GET / Accept: application/json+userdb

响应 

 200 OK Content-Type: application/json+userdb { "version": "1.0", "links": [ { "href": "/user", "rel": "list", "method": "GET" }, { "href": "/user", "rel": "create", "method": "POST" } ] }

从我们媒体的描述中我们知道，我们可以从“链接”部分find关于相关资源的信息。 这被称为超媒体控件 。 在这种情况下，我们可以从这个部分看出，我们可以通过再次请求/user来find一个用户列表：

请求 

 GET /user Accept: application/json+userdb

响应 

 200 OK Content-Type: application/json+userdb { "users": [ { "id": 1, "name": "Emil", "country: "Sweden", "links": [ { "href": "/user/1", "rel": "self", "method": "GET" }, { "href": "/user/1", "rel": "edit", "method": "PUT" }, { "href": "/user/1", "rel": "delete", "method": "DELETE" } ] }, { "id": 2, "name": "Adam", "country: "Scotland", "links": [ { "href": "/user/2", "rel": "self", "method": "GET" }, { "href": "/user/2", "rel": "edit", "method": "PUT" }, { "href": "/user/2", "rel": "delete", "method": "DELETE" } ] } ], "links": [ { "href": "/user", "rel": "create", "method": "POST" } ] }

我们可以从这个回应中看出很多。 例如，我们现在知道我们可以通过发送到/user来创build一个新/user ：

请求 

 POST /user Accept: application/json+userdb Content-Type: application/json+userdb { "name": "Karl", "country": "Austria" }

响应 

 201 Created Content-Type: application/json+userdb { "user": { "id": 3, "name": "Karl", "country": "Austria", "links": [ { "href": "/user/3", "rel": "self", "method": "GET" }, { "href": "/user/3", "rel": "edit", "method": "PUT" }, { "href": "/user/3", "rel": "delete", "method": "DELETE" } ] }, "links": { "href": "/user", "rel": "list", "method": "GET" } }

我们也知道我们可以改变现有的数据：

请求 

 PUT /user/1 Accept: application/json+userdb Content-Type: application/json+userdb { "name": "Emil", "country": "Bhutan" }

响应 

 200 OK Content-Type: application/json+userdb { "user": { "id": 1, "name": "Emil", "country": "Bhutan", "links": [ { "href": "/user/1", "rel": "self", "method": "GET" }, { "href": "/user/1", "rel": "edit", "method": "PUT" }, { "href": "/user/1", "rel": "delete", "method": "DELETE" } ] }, "links": { "href": "/user", "rel": "list", "method": "GET" } }

请注意，我们正在使用不同的HTTP动词（GET，PUT，POST，DELETE等）来操纵这些资源，而我们在客户端部分中唯一的知识就是我们的媒体定义。

进一步阅读：

  • 在这个页面上有很多更好的答案。
  • 我如何向我的妻子解释REST 。
  • 我如何向我的妻子解释REST 。
  • 马丁·福勒的想法
  • 贝宝的API有超媒体控件

（这个答案因为缺less这个观点而受到了相当多的批评，大多数情况下这是一个公正的批评，原来我所描述的更像是几年前通常如何实现REST首先写这个，而不是真正的意思，我已经修改了答案，以更好地代表真正的意思。）

RESTful编程是关于：

  • 资源由一个持久的标识符来标识：URI是目前标识符无处不在的select
  • 资源被操作使用一个共同的动词：HTTP方法是常见的情况 – 历史悠久的Create ， Retrieve ， Update ， Delete成为POST ， GET ， PUT和DELETE 。 但REST并不局限于HTTP，它只是现在最常用的传输方式。
  • 为资源检索的实际表示取决于请求而不是标识符：使用Accept标头来控制是否需要XML，HTTP甚至表示资源的Java对象
  • 保持对象中的状态并在表示中表示状态
  • 表示资源表示中资源之间的关系：对象之间的链接直接embedded到表示中
  • 资源表示描述如何使用该表示，以及在什么情况下应该以一致的方式丢弃/重新获取：使用HTTPcaching控制报头

就REST的后果和总体效果而言，最后一个可能是最重要的。 总的来说，大多数RESTful讨论似乎都集中在HTTP及其在浏览器中的使用，而不是什么。 我知道R.Fielding在描述导致HTTP的体系结构和决定时创造了这个术语。 他的论文更多的是关于资源的架构和caching能力，而不是HTTP。

如果你真的对RESTful体系结构是什么感兴趣，为什么它有效，请阅读他的论文几次，不仅仅阅读第5章！ 接下来看看为什么DNS工作 。 阅读有关DNS的分层结构以及参照如何工作。 然后阅读并考虑DNScaching如何工作。 最后，阅读HTTP规范（特别是RFC2616和RFC3040 ），并考虑caching如何以及为什么如此工作。 最终，它只会点击。 对我来说最后的启示是当我看到DNS和HTTP之间的相似性。 在此之后，了解为什么SOA和消息传递接口可扩展性开始点击。

我认为理解RESTful和Shared Nothing体系结构的体系结构重要性和性能影响的最重要技巧是避免挂上技术和实现细节。 关注谁拥有资源，谁负责创build/维护这些资源等。然后考虑表示，协议和技术。

这可能是这样的。

用三个属性创build一个用户： 

 POST /user fname=John&lname=Doe&age=25

服务器响应： 

 200 OK Location: /user/123

将来，您可以检索用户信息： 

 GET /user/123

服务器响应： 

 200 OK <fname>John</fname><lname>Doe</lname><age>25</age>

修改logging（ lname和age将保持不变）： 

 PATCH /user/123 fname=Johnny

更新logging（因此lname和age将为NULL）： 

 PUT /user/123 fname=Johnny

关于REST的一本很好的书是REST的实践 。

必须读取的是Representational State Transfer（REST），而REST API必须是超文本驱动的

请参阅Martin Fowlers的“ Richardson成熟度模型 （RMM）”文章，了解REST风格的服务是什么。

理查森成熟度模型

为了成为RESTful的服务需要实现超媒体作为应用程序状态的引擎。 （HATEOAS） ，也就是说，它需要达到RMM中的第三级， 阅读文章的细节或从qcon谈话的幻灯片 。

HATEOAS约束是Hypermedia作为应用程序状态引擎的首字母缩写。 这个原则是REST和大多数其他forms的客户服务器系统之间的关键区别。

…

RESTful应用程序的客户端只需要知道一个固定的URL即可访问它。 将来的所有操作都应该从包含在从该URL返回的资源表示中的超媒体链接中dynamic发现。 任何可能使用RESTful API的客户端都可以理解标准化的媒体types。 （维基百科，自由的百科全书）

REST对Web框架的Litmustesting对于Web框架是一个类似的成熟度testing。

走近纯粹的REST：学习爱HATEOAS是一个很好的链接集合。

REST与公有云的SOAP讨论了REST使用的当前级别。

REST和版本化通过可修改性讨论了可扩展性，版本控制，可演化性等

什么是REST？

REST代表具象状态转移。 （有时拼写为“ReST”）。它依赖于无状态的客户端服务器，可caching的通信协议 – 几乎在所有情况下都使用HTTP协议。

REST是devisenetworking应用程序的架构风格。 这个想法是，不是使用诸如CORBA，RPC或SOAP之类的复杂机制来连接机器，而是使用简单的HTTP在机器之间进行调用。

在许多方面，基于HTTP的万维网本身可以被视为基于REST的架构。 RESTful应用程序使用HTTP请求来发布数据（创build和/或更新），读取数据（例如，查询）以及删除数据。 因此，REST对所有四个CRUD（创build/读取/更新/删除）操作使用HTTP。

REST是RPC（远程过程调用）和Web服务（SOAP，WSDL等）机制的轻量级替代scheme。 稍后，我们将看到更简单的REST是多less。

尽pipe简单，RESTfunction齐全; 在Web服务中，基本上没有什么可以做到的，而RESTful体系结构无法做到这一点。 REST不是一个“标准”。 例如，REST永远不会有W3C推荐标准。 虽然有REST编程框架，但使用REST非常简单，您可以经常使用Perl，Java或C＃等语言的标准库function“滚动自己”。

当我试图findrest的简单真正意义时，我发现了最好的参考之一。

http://rest.elkstein.org/

REST使用各种HTTP方法（主要是GET / PUT / DELETE）来处理数据。

您可以发送DELETE请求到/user/[id] URL，编辑用户，检索您发送的用户的信息，而不是使用特定的URL来删除一个方法（比如/user/123/delete ） GET请求/user/[id]

例如，而不是一组可能看起来像下面的一些URL .. 

 GET /delete_user.x?id=123 GET /user/delete GET /new_user.x GET /user/new GET /user?id=1 GET /user/id/1

你使用HTTP“动词”，并有.. 

 GET /user/2 DELETE /user/2 PUT /user

它是编程的地方，你的系统架构符合Roy Fielding在他的论文中提出的REST风格 。 由于这是描述networking的build筑风格（或多或less），很多人对此感兴趣。

奖励答案：否。除非您正在学习软件架构作为学术或deviseWeb服务，否则没有理由听到这个术语。

我会说RESTful编程是关于创build遵循REST架构风格的系统（API）。

我发现M. Elkstein博士写了一篇关于REST的精彩，简短，易于理解的教程，并引用了可以回答您的问题的重要部分：

学习REST：教程

REST是devisenetworking应用程序的架构风格 。 这个想法是，不是使用诸如CORBA，RPC或SOAP之类的复杂机制来连接机器，而是使用简单的HTTP在机器之间进行调用。

  • 在许多方面，基于HTTP的万维网本身可以被视为基于REST的架构。

REST风格的应用程序使用HTTP请求发布数据（创build和/或更新），读取数据（例如，查询）和删除数据。 因此，REST对所有四个CRUD（创build/读取/更新/删除）操作使用HTTP。

我不认为你应该感到愚蠢的，因为没有听到关于栈溢出之外的REST，我将是在相同的情况！ 回答这个问题， 为什么REST变得很大，现在可以缓解一些感觉。

如果我没有直接回答这个问题，我很抱歉，但是通过更详细的例子可以更容易地理解这一切。 由于所有的抽象和术语，Fielding并不容易理解。

这里有一个很好的例子：

解释REST和超文本：Spam-E垃圾清理机器人

更好的是，这里有一个简单的例子（这个简单的例子更全面，但是你可以在html版本中获得大部分内容）：

http://www.xfront.com/REST.ppt或http://www.xfront.com/REST.html

看完这些例子后，我明白了Ken为什么说REST是超文本驱动的。 实际上我并不确定他是对的，因为/ user / 123是一个指向资源的URI，我不清楚这是否是不可靠的，因为客户知道它是“带外的”。

这个xfront文档解释了REST和SOAP之间的区别，这也是非常有用的。 当Fielding说：“ 这是RPC，它尖叫着RPC ”，显然RPC不是RESTful的，因此查看确切的原因是很有用的。 （SOAP是一种RPC。）

什么是REST？

用官方语言REST，REST是一种基于当前“Web”基础而build立在某些原则基础上的架构风格。 Web有5个基本的基础，可以用来创buildREST服务。

  • 原则1：一切都是资源在REST架构风格中，数据和function被视为资源，并使用统一资源标识符（URI）（通常是Web上的链接）进行访问。
  • 原则2：每个资源都由唯一标识符（URI）标识
  • 原则3：使用简单和统一的接口
  • 原则4：通过表示进行沟通
  • 原则5：无国籍

我看到一堆答案说，把资源“/ user / 123”上的用户123的一切都是RESTful。

创造该术语的Roy Fielding说， REST API必须是超文本驱动的 。 特别是，“REST API不能定义固定的资源名称或层次结构”。

所以如果你的“/ user / 123”path在客户端被硬编码，那么它不是真正的RESTful。 很好的使用HTTP，也许可能不是。 但不是RESTful。 它必须来自超文本。

答案很简单，有一篇由Roy Fielding写的论文 。] 1在他的论文中，他定义了REST原则。 如果一个应用程序满足所有这些原则，那么这是一个REST应用程序。

术语RESTful是由于ppl通过将它们的非REST应用程序称为REST而耗尽了REST这个词来创build的。 之后，RESTful这个词也被耗尽了。 现在我们正在谈论Web API和超媒体API ，因为大多数所谓的REST应用程序不能满足统一接口约束的HATEOAS部分。

REST约束如下：

  1. 客户端 – 服务器架构

    所以它不适用于例如PUB / SUB套接字，它基于REQ / REP。

  2. 无国籍的沟通

    所以服务器不维护客户端的状态。 这意味着你不能使用服务器端会话存储，你必须authentication每一个请求。 您的客户端可能通过encryption连接发送基本身份validation标头。 （通过大型应用程序很难保持多个会话。）

  3. 如果可以的话，使用caching

    所以你不必一次又一次地提供相同的请求。

  4. 统一接口作为客户端和服务器之间的通用契约

    客户端和服务器之间的合同不是由服务器维护的。 换句话说，客户端必须与服务的实现分离。 您可以通过使用标准解决scheme来达到此状态，例如标识资源的IRI（URI）标准，交换消息的HTTP标准，描述正文序列化格式的标准MIMEtypes，元数据（可能是RDF词汇，微格式等）描述消息体的不同部分的语义。 为了将IRI结构从客户端分离出来，你必须以超媒体格式（HTML，JSON-LD，HAL等）发送超链接到客户端。 因此，客户端可以使用分配给超链接的元数据（可能链接关系，RDF词汇表）通过适当的状态转换来导航应用程序的状态机，以实现其当前目标。

    例如，当一个客户想要发送一个订单到一个网上商店，那么它必须检查网上商店发送的回复中的超链接。 通过检查链接find一个描述与http://schema.org/OrderAction 。 客户端知道schema.org词汇，所以它明白，通过激活这个超链接，它会发送订单。 所以它激活超链接，并发送POST https://example.com/api/v1/order消息与正确的机构。 之后，服务处理消息，并响应具有正确的HTTP状态头的结果，例如201 - created由成功201 - created 。 使用详细元数据注释消息使用RDF格式的标准解决scheme，例如带有REST词汇的JSON-LD ，例如Hydra和域特定的词汇表，如schema.org或任何其他链接的数据词汇表 ，也可能是定制的特定于应用程序的词汇表if需要。 现在这并不容易，这就是为什么大多数人使用HAL和其他简单的格式，通常只提供一个REST词汇，但没有链接的数据支持。

  5. 构build分层系统以提高可伸缩性

    REST系统由分层结构组成。 每个图层包含使用下面图层中组件的服务的组件。 所以你可以毫不费力地添加新的图层和组件。

    例如，有一个包含客户端的客户端层，下面有一个包含单个服务的服务层。 现在你可以在它们之间添加一个客户端caching。 之后，您可以添加另一个服务实例和一个负载平衡器，依此类推…客户端代码和服务代码不会改变。

  6. 按需代码扩展客户端function

    这个约束是可选的。 例如，您可以将特定媒体types的parsing器发送到客户端，等等…为了做到这一点，您可能需要在客户端使用标准的插件加载器系统，否则您的客户端将连接到插件加载器解决scheme。

REST约束产生一个高度可扩展的系统，客户端与服务的实现分离。 所以客户可以重复使用，就像networking上的浏览器一样。 客户和服务共享相同的标准和词汇，尽pipe客户不知道服务的实现细节，但他们可以相互了解。 这使得创build自动化客户端成为可能，这些客户端可以find并利用REST服务来实现其目标。 从长远来看，这些客户可以像对待人一样，互相沟通，互相信任。 如果我们为这些客户添加学习模式，那么结果将是使用机器网而不是单个服务器园的一个或多个AI。 所以最后伯纳斯·李的梦想：语义networking和人工智能将成为现实。 所以在2030年，我们最终被天网终止。 直到那时 … ;-）

RESTful （Representational state transfer）具有代表性的状态转移（API）编程是遵循5种基本的软件架构风格原则，用任何编程语言编写web应用程序：

  1. 资源（数据，信息）。
  2. 唯一的全球标识符 （所有资源都是由URI唯一标识的）。
  3. 统一接口 – 使用简单和标准的接口（HTTP）。
  4. 表示 – 所有通信都是通过表示（例如XML / JSON ）
  5. 无状态 （每个请求完全隔离，更容易caching和负载平衡），

In other words you're writing simple point-to-point network applications over HTTP which uses verbs such as GET, POST, PUT or DELETE by implementing RESTful architecture which proposes standardization of the interface each “resource” exposes. It is nothing that using current features of the web in a simple and effective way (highly successful, proven and distributed architecture). It is an alternative to more complex mechanisms like SOAP , CORBA and RPC .

RESTful programming conforms to Web architecture design and, if properly implemented, it allows you to take the full advantage of scalable Web infrastructure.

Here is my basic outline of REST. I tried to demonstrate the thinking behind each of the components in a RESTful architecture so that understanding the concept is more intuitive. Hopefully this helps demystify REST for some people!

REST (Representational State Transfer) is a design architecture that outlines how networked resources (ie nodes that share information) are designed and addressed. In general, a RESTful architecture makes it so that the client (the requesting machine) and the server (the responding machine) can request to read, write, and update data without the client having to know how the server operates and the server can pass it back without needing to know anything about the client. Okay, cool…but how do we do this in practice?

  • The most obvious requirement is that there needs to be a universal language of some sort so that the server can tell the client what it is trying to do with the request and for the server to respond.

  • But to find any given resource and then tell the client where that resource lives, there needs to be a universal way of pointing at resources. This is where Universal Resource Identifiers (URIs) come in; they are basically unique addresses to find the resources.

But the REST architecture doesn't end there! While the above fulfills the basic needs of what we want, we also want to have an architecture that supports high volume traffic since any given server usually handles responses from a number of clients. Thus, we don't want to overwhelm the server by having it remember information about previous requests.

  • Therefore, we impose the restriction that each request-response pair between the client and the server is independent, meaning that the server doesn't have to remember anything about previous requests (previous states of the client-server interaction) to respond to a new request. This means that we want our interactions to be stateless.

  • To further ease the strain on our server from redoing computations that have already been recently done for a given client, REST also allows caching. Basically, caching means to take a snapshot of the initial response provided to the client. If the client makes the same request again, the server can provide the client with the snapshot rather than redo all of the computations that were necessary to create the initial response. However, since it is a snapshot, if the snapshot has not expired–the server sets an expiration time in advance–and the response has been updated since the initial cache (ie the request would give a different answer than the cached response), the client will not see the updates until the cache expires (or the cache is cleared) and the response is rendered from scratch again.

  • The last thing that you'll often here about RESTful architectures is that they are layered. We have actually already been implicitly discussing this requirement in our discussion of the interaction between the client and server. Basically, this means that each layer in our system interacts only with adjacent layers. So in our discussion, the client layer interacts with our server layer (and vice versa), but there might be other server layers that help the primary server process a request that the client does not directly communicate with. Rather, the server passes on the request as necessary.

Now, if all of this sounds familiar, then great. The Hypertext Transfer Protocol (HTTP), which defines the communication protocol via the World Wide Web is an implementation of the abstract notion of RESTful architecture (or an instance of the REST class if you're an OOP fanatic like me). In this implementation of REST, the client and server interact via GET, POST, PUT, DELETE, etc., which are part of the universal language and the resources can be pointed to using URLs.

If I had to reduce the original dissertation on REST to just 3 short sentences, I think the following captures its essence:

  1. Resources are requested via URLs.
  2. Protocols are limited to what you can communicate by using URLs.
  3. Metadata is passed as name-value pairs (post data and query string parameters).

After that, it's easy to fall into debates about adaptations, coding conventions, and best practices.

Interestingly, there is no mention of HTTP POST, GET, DELETE, or PUT operations in the dissertation. That must be someone's later interpretation of a "best practice" for a "uniform interface".

When it comes to web services, it seems that we need some way of distinguishing WSDL and SOAP based architectures which add considerable overhead and arguably much unnecessary complexity to the interface. They also require additional frameworks and developer tools in order to implement. I'm not sure if REST is the best term to distinguish between common-sense interfaces and overly engineered interfaces such as WSDL and SOAP. But we need something.

Representational State Transfer (REST) is a software architecture style consisting of guidelines and best practices for creating scalable web services.REST is a coordinated set of constraints applied to the design of components in a distributed hypermedia system that can lead to a more performant and maintainable architecture.

REST has gained widespread acceptance across the Web[citation needed] as a simpler alternative to SOAP and WSDL-based Web services. RESTful systems typically, but not always, communicate over the Hypertext Transfer Protocol with the same HTTP verbs (GET, POST, PUT, DELETE, etc.) used by web browsers to retrieve web pages and send data to remote servers.

The REST architectural style was developed by W3C Technical Architecture Group (TAG) in parallel with HTTP 1.1, based on the existing design of HTTP 1.0. The World Wide Web represents the largest implementation of a system conforming to the REST architectural style.

Architectural constraints

The architectural properties of REST are realized by applying specific interaction constraints to components, connectors, and data elements. The formal REST constraints are:

Client–server

A uniform interface separates clients from servers. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that the portability of client code is improved. Servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable. Servers and clients may also be replaced and developed independently, as long as the interface between them is not altered.

Stateless

The client–server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all the information necessary to service the request, and session state is held in the client. The session state can be transferred by the server to another service such as a database to maintain a persistent state for a period and allow authentication. The client begins sending requests when it is ready to make the transition to a new state. While one or more requests are outstanding, the client is considered to be in transition. The representation of each application state contains links that may be used the next time the client chooses to initiate a new state-transition.

Cacheable

As on the World Wide Web, clients can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients from reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance.

Layered system

A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load balancing and by providing shared caches. They may also enforce security policies.

Code on demand (optional)

Servers can temporarily extend or customize the functionality of a client by the transfer of executable code. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript. "Code on demand" is the only optional constraint of the REST architecture.

Uniform interface

The uniform interface constraint is fundamental to the design of any REST service.The uniform interface simplifies and decouples the architecture, which enables each part to evolve independently.

REST is an architectural pattern and style of writing distributed applications. It is not a programming style in the narrow sense.

Saying you use the REST style is similar to saying that you built a house in a particular style: for example Tudor or Victorian. Both REST as an software style and Tudor or Victorian as a home style can be defined by the qualities and constraints that make them up. For example REST must have Client Server separation where messages are self-describing. Tudor style homes have Overlapping gables and Roofs that are steeply pitched with front facing gables. You can read Roy's dissertation to learn more about the constraints and qualities that make up REST.

REST unlike home styles has had a tough time being consistently and practically applied. This may have been intentional. Leaving its actual implementation up to the designer. So you are free to do what you want so as long as you meet the constraints set out in the dissertation you are creating REST Systems.

Bonus:

The entire web is based on REST (or REST was based on the web). Therefore as a web developer you might want aware of that although it's not necessary to write good web apps.

I think the point of restful is the separation of the statefulness into a higher layer while making use of the internet (protocol) as a stateless transport layer . Most other approaches mix things up.

It's been the best practical approach to handle the fundamental changes of programming in internet era. Regarding the fundamental changes, Erik Meijer has a discussion on show here: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . He summarizes it as the five effects, and presents a solution by designing the solution into a programming language. The solution, could also be achieved in the platform or system level, regardless of the language. The restful could be seen as one of the solutions that has been very successful in the current practice.

With restful style, you get and manipulate the state of the application across an unreliable internet. If it fails the current operation to get the correct and current state, it needs the zero-validation principal to help the application to continue. If it fails to manipulate the state, it usually uses multiple stages of confirmation to keep things correct. In this sense, rest is not itself a whole solution, it needs the functions in other part of the web application stack to support its working.

Given this view point, the rest style is not really tied to internet or web application. It's a fundamental solution to many of the programming situations. It is not simple either, it just makes the interface really simple, and copes with other technologies amazingly well.

Just my 2c.

Edit: Two more important aspects:

  • Statelessness is misleading. It is about the restful API, not the application or system. The system needs to be stateful. Restful design is about designing a stateful system based on a stateless API. Some quotes from another QA :

    • REST, operates on resource representations, each one identified by an URL. These are typically not data objects, but complex objects abstractions .
    • REST stands for "representational state transfer", which means it's all about communicating and modifying the state of some resource in a system.

  • Idempotence : An often-overlooked part of REST is the idempotency of most verbs. That leads to robust systems and less interdependency of exact interpretations of the semantics .

Quote from another post: "

There is not such notion as "RESTful programming" per se. It would be better called RESTful paradigm or even better RESTful architecture. It is not a programming language. It is a paradigm.

维基百科 ：

In computing, representational state transfer (REST) is an architectural style used for web development.

This is amazingly long "discussion" and yet quite confusing to say the least.

IMO:

1) There is no such a thing as restful programing, without a big joint and lots of beer 🙂

2) Representational State Transfer (REST) is an architectural style specified in the dissertation of Roy Fielding . It has a number of constraints. If your Service/Client respect those then it is RESTful. This is it.

You can summarize(significantly) the constraints to :

  • stateless communication
  • respect HTTP specs (if HTTP is used)
  • clearly communicates the content formats transmitted
  • use hypermedia as the engine of application state

There is another very good post which explains things nicely.

A lot of answers copy/pasted valid information mixing it and adding some confusion. People talk here about levels, about RESTFul URIs(there is not such a thing!), apply HTTP methods GET,POST,PUT … REST is not about that or not only about that.

For example links – it is nice to have a beautifully looking API but at the end the client/server does not really care of the links you get/send it is the content that matters.

In the end any RESTful client should be able to consume to any RESTful service as long as the content format is known.

The point of rest is that if we agree to use a common language for basic operations (the http verbs), the infrastructure can be configured to understand them and optimize them properly, for example, by making use of caching headers to implement caching at all levels.

With a properly implemented restful GET operation, it shouldn't matter if the information comes from your server's DB, your server's memcache, a CDN, a proxy's cache, your browser's cache or your browser's local storage. The fasted, most readily available up to date source can be used.

Saying that Rest is just a syntactic change from using GET requests with an action parameter to using the available http verbs makes it look like it has no benefits and is purely cosmetic. The point is to use a language that can be understood and optimized by every part of the chain. If your GET operation has an action with side effects, you have to skip all HTTP caching or you'll end up with inconsistent results.

REST stands for Representational state transfer .

It relies on a stateless, client-server, cacheable communications protocol — and in virtually all cases, the HTTP protocol is used.

REST is often used in mobile applications, social networking Web sites, mashup tools and automated business processes. The REST style emphasizes that interactions between clients and services is enhanced by having a limited number of operations (verbs). Flexibility is provided by assigning resources (nouns) their own unique universal resource indicators (URIs).

Introduction about Rest

Old question, newish way of answering. There's a lot of misconception out there about this concept. I always try to remember:

  1. Structured URLs and Http Methods/Verbs are not the definition of restful programming.
  2. JSON is not restful programming
  3. RESTful programming is not for APIs

I define restful programming as

An application is restful if it provides resources (being the combination of data + state transitions controls) in a media type the client understands

To be a restful programmer you must be trying to build applications that allow actors to do things. Not just exposing the database.

State transition controls only make sense if the client and server agree upon a media type representation of the resource. Otherwise there's no way to know what's a control and what isn't and how to execute a control. IE if browsers didn't know tags in html then there'd be nothing for you to submit to transition state in your browser.

I'm not looking to self promote, but i expand on these ideas to great depth in my talk http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .

REST === HTTP analogy is not correct until you do not stress to the fact that it "MUST" be HATEOAS driven.

Roy himself cleared it here .

A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (ie, expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user's manipulation of those representations. The transitions may be determined (or limited by) the client's knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (eg, code-on-demand).

[Failure here implies that out-of-band information is driving interaction instead of hypertext.]

Talking is more than simply exchanging information . A Protocol is actually designed so that no talking has to occur. Each party knows what their particular job is because it is specified in the protocol. Protocols allow for pure information exchange at the expense of having any changes in the possible actions. Talking, on the other hand, allows for one party to ask what further actions can be taken from the other party. They can even ask the same question twice and get two different answers, since the State of the other party may have changed in the interim. Talking is RESTful architecture . Fielding's thesis specifies the architecture that one would have to follow if one wanted to allow machines to talk to one another rather than simply communicate .

What is API Testing ?

API testing utilizes programming to send calls to the API and get the yield. It testing regards the segment under test as a black box. The objective of API testing is to confirm right execution and blunder treatment of the part preceding its coordination into an application.

REST API

REST: Representational State Transfer.

  • It's an arrangement of functions on which the testers performs requests and receive responses. In REST API interactions are made via HTTP protocol.
  • REST also permits communication between computers with each other over a network.
  • For sending and receiving messages, it involves using HTTP methods, and it does not require a strict message definition, unlike Web services.
  • REST messages often accepts the form either in form of XML, or JavaScript Object Notation (JSON).

4 Commonly Used API Methods:-

  1. GET: – It provides read only access to a resource.
  2. POST: – It is used to create or update a new resource.
  3. PUT: – It is used to update or replace an existing resource or create a new resource.
  4. DELETE: – It is used to remove a resource.

Steps to Test API Manually:-

To use API manually, we can use browser based REST API plugins.

  1. Install POSTMAN(Chrome) / REST(Firefox) plugin
  2. Enter the API URL
  3. Select the REST method
  4. Select content-Header
  5. Enter Request JSON (POST)
  6. Click on send
  7. It will return output response

Steps to Automate REST API

REST is an architectural style which is based on web-standards and the HTTP protocol. This style was initially described by Roy Fielding in 2000. In a REST based architecture everything is a resource. A resource is accessed via a common interface based on the HTTP standard methods. In a REST based architecture you have a REST server which provides access to the resources. A REST client can access and modify the REST resources.

Every resource should support the HTTP common operations. Resources are identified by global IDs (which are typically URIs).

REST allows that resources have different representations, eg, text, XML, JSON etc. The REST client can ask for a specific representation via the HTTP protocol (content negotiation).

HTTP methods:

The PUT, GET, POST and DELETE methods are typical used in REST based architectures. The following table gives an explanation of these operations.

  • GET defines a reading access of the resource without side-effects. The resource is never changed via a GET request, eg, the request has no side effects (idempotent).
  • PUT creates a new resource. It must also be idempotent.
  • DELETE removes the resources. The operations are idempotent. They can get repeated without leading to different results.
  • POST updates an existing resource or creates a new resource.

REST defines 6 architectural constraints which make any web service – a true RESTful API .

  1. Uniform interface
  2. Client–server
  3. Stateless
  4. Cacheable
  5. Layered system
  6. Code on demand (optional)

https://restfulapi.net/rest-architectural-constraints/

This is very less mentioned everywhere but the Richardson's Maturity Model is one of the best methods to actually judge how Restful is one's API. More about it here:

Richardson's Maturity Model

Interesting Posts

软件devise与软件架构

什么“闭包”在JavaScript中引用？

单元，function，验收和集成testing有什么区别？

为什么class {int i; }; 不完全符合标准？

什么是“线程”（真的）？

如何在运行时find方法的定义？

在CUDA中，什么是内存聚合，它是如何实现的？

启发式和algorithm之间有什么区别？

伪装，嘲弄和剔除有什么区别？

什么是样板代码？