soap rest

I’ve read the philosophical dissertations, so you don’t have to!

我已经读过哲学论文，所以您不必！

I expected my recent article (or “hipsteresque drunken rant,” as some called it), to get a barrage of criticism, under the motto “you haven’t understood anything about REST.” It indeed happened.

我期望我最近的文章 (或称“时髦的醉汉”，有人称其为“大批批评”)的座右铭是“您对REST一无所知”。 确实发生了。

But it also sparked interesting debates, especially on Reddit and on Hacker News. It also struck a cord in numerous developers, who felt like heretics for doubting the almightiness of REST.

但这也引发了有趣的辩论，尤其是在Reddit和Hacker News上 。 它也打动了许多开发人员，他们对REST的全能性表示怀疑，这就像异端一样。

To quote a particularly insightful summary of the resentment:

引用一份特别有见地的怨恨摘要 ：

A simple RPC API spec takes minutes to define. ‘Rest’ifying takes much longer, there are a million little gotchas, no real standard. Everyone has a different opinion of how it should be done.

一个简单的RPC API规范需要几分钟的时间来定义。 “重新整理”花费的时间更长，有一百万个小陷阱，没有真正的标准。 每个人对应该如何做都有不同的看法。

Data is spread across verbs, urls, query params, headers, and payloads. Everyone thinks everyone else doesn’t ‘get’ REST. If you try to suggest something other than REST in the office you become the subject of a witch hunt. It really is a cargo cult of pointlessness.

数据分布在动词，URL，查询参数，标头和有效载荷上。 每个人都认为其他人没有“获得” REST。 如果您在办公室中建议使用REST以外的其他方法，那么您将成为猎巫的对象。 这确实是一种毫无意义的追求。

My co-workers have spent sooo much time trying to get Swagger to generate documentation correctly as well as generate client side APIs, and there are countless gotchas we are still dealing with. It really is SOAP 2.0, when a simple JSON/RPC protocol would have done fine.

我的同事们花了很多时间来尝试使Swagger正确生成文档以及生成客户端API，并且我们仍在处理无数的陷阱。 当一个简单的JSON / RPC协议可以正常工作时，它的确是SOAP 2.0。

Don’t get me started with conflating HTTP server errors with applications errors. And trying to do action-like requests with a mindset optimized for CRUD. How much time have we wasted figuring out the ‘standard’ way to do just a login API call RESTfully.

不要让我开始将HTTP服务器错误与应用程序错误混为一谈。 并尝试以针对CRUD进行优化的思维方式来执行类似操作的请求。 我们浪费了多少时间来弄清楚仅进行REST API登录API调用的“标准”方法。

On the opposite side, Phil Sturgeon, one of the main advocates of REST, released a response article (see my quick comments here). I’m glad we agreed on some important points, especially that many APIs actually ought to be RPC, instead of ending as pseudo-REST patch-up jobs.

相反，REST的主要倡导者之一的Phil Sturgeon发表了一篇回应文章 (请参阅此处的快速评论 )。 我很高兴我们在一些重要点上达成了共识，尤其是许多API实际上应该是RPC，而不是作为伪REST修补工作结束。

In the light of all this feedback, I’ve edited my initial essay quite a few times, and now a new article seems necessary to clarify the remaining points.

根据所有这些反馈，我对我的第一篇论文进行了多次编辑，现在看来有必要撰写一篇新文章来阐明其余要点。

I would like to apologize in advance if the cheekiness of this post comes across as rudeness. Considering the harmfulness of the situation, I alas couldn’t content myself of a peaceful tone. No personal offense is meant in any way. So let’s get on with it.

如果这篇文章的内容过于粗鲁无礼，谨在此致歉。 考虑到局势的危害性，我a不能满足于和平的语气。 绝不意味着人身犯罪。 因此，让我们继续吧。

几种不同的REST (Several shades of REST)

One difficulty of the subject is that there are several concepts behind the term “REST.”

该主题的一个难题是“ REST”一词背后有多个概念。

1) The Founding Book of REST, i.e the dissertation of Roy Fielding 2) The thousands of blogposts/podcasts of REST advocates (like Phil Sturgeon’s), disseminated on the Web, and explaining “how to do REST properly”3) The gazillions of (self-proclaimed) RESTful webservices, publicly or privately exposed all over the Internet

1)REST的创始书，即Roy Fielding的论文 2)数千种REST倡导者的博客文章/播客(如Phil Sturgeon's)在网络上传播，并解释了“如何正确进行REST” 3) (自称)RESTful Web服务，在Internet上公开或私下公开

My rant was mostly dealing with #3: the RESTish APIs that are wasting everyone’s time, for yet-to-be-demonstrated benefits. And even after reading hundreds of comments, I have to stand my ground: these APIs that I’ve met everywhere are constantly reinventing the wheel, don’t even leverage the advantages that HTTP semantics could bring (client-side caching, content negotiation, optimistic locking…), and are a lengthy pain to integrate.

我的咆哮大部分是在处理＃3： RESTish API浪费了每个人的时间，以带来尚未证明的好处。 即使阅读了数百条评论，我也必须坚持自己的立场：我到处都遇到的这些API一直在不断革新，甚至没有利用HTTP语义所带来的优势(客户端缓存，内容协商，乐观锁定...)，并且整合起来是一个漫长的痛苦。

The response article by Phil Sturgeon highlighted the main reason for this epitome of pointlessness:

Phil Sturgeon的回应文章强调了这种毫无意义的缩影的主要原因：

“Folks everywhere are building RESTish APIs which are basically just RPC + HTTP verbs + Pretty URLs.”

“ 各地的人们都在构建RESTish API，这些API基本上只是RPC + HTTP动词+漂亮的URL。 ”

Along the way, we evoked #2 through some quotes of REST advocates. For the rest, as far as I’ve seen, REST bloggers/podcasters have often contradicted each other. They’ve given instructions that sounded more like tastes than wisdom lessons, have evaded the most important questions, and have made a virtue of not backing, with examples and demonstrations, their most audacious arguments: “RPC causes redundant work”, “REST is necessary for APIs lasting decades”, and of course the (in)famous “The client does not need any prior knowledge of the service in order to use it.”

在此过程中，我们通过REST倡导者的一些引述引起了＃2的注意 。 就其他方面而言，据我所知，REST博客/播客经常相互矛盾。 他们给出的指示听起来更像是口味，而不是智慧的教训，他们回避了最重要的问题，并凭借示例和演示不支持他们的最大胆的论点： “ RPC导致多余的工作” ， “ REST是是持续数十年的API所必需的” ，当然(众所周知) “客户不需要任何有关服务的先验知识即可使用它。”

I’ve not yet crossed a simple page of prose summarizing how HATEOAS really works, and what challenges it solves for us. This is a problem in itself.

我还没有跨过一个简单的散文页面，总结了HATEOAS的真正工作方式以及它为我们解决的挑战。 这本身就是一个问题。

About contradictions…here’s an anecdote. When I showcased a simple (and gently CRUD-oriented) API, it was just to show the abnormal number of questions that had to be answered just to RESTify it. And still, numbers of commenters felt compelled to explain, with verbose documentation, how THEY would specify this API.

关于矛盾……这里有个轶事。 当我展示一个简单的(面向CRUD的)简单API时，它只是为了说明要还原它所必须回答的异常数量的问题。 而且，许多评论者仍被迫用冗长的文档解释他们将如何指定此API。

It resulted in lots of similar but incompatible protocols, some weaving standards together, some reinventing carved flintstone, and some going as far as specifying a versioned MIME type per Resource endpoint (like “application/vnd.my-rest-api.v1.account-search-result+json”).

它导致了许多相似但不兼容的协议，一些编织标准融合在一起，一些重新发明了雕刻的打火石，还有一些甚至为每个Resource端点指定了版本化的MIME类型(例如“ application / vnd.my-rest-api.v1.account” -search-result + json” )。

Phil Sturgeon also answered, in his response article, these semi-rhetorical questions. The recommendations delivered made sense and seemed “up to date.” But they directly contradicted the past or present teachings of lots of other REST proponents (as well as commenters cited above) on diverse subjects: sparse fields, compounds documents, PATCH formats, DELETE payloads, and so on.

菲尔·斯特金(Phil Sturgeon)在回答文章中还回答了这些半修辞性的问题。 所提供的建议是合理的，并且似乎是“最新的”。 但是它们直接与过去或现在的许多其他REST支持者(以及上面引用的评论者)关于不同主题的教义相抵触：稀疏字段，复合文档，PATCH格式，DELETE负载等等。

At least all this proved a point: when things must be done quickly and consensually, REST is not the best way to go. Still, many claimed that I was attacking “misconceptions” of REST, and directed me to this or that quote from the original dissertation. This was a way of saying that the “theory” was good, even though the “practice” was flawed. “Yeah, right, communism claims the same,” one might argue.

至少所有这些都证明了这一点：必须快速而明智地完成工作时，REST并不是最好的选择。 但是，许多人仍然声称我在攻击REST的“误解”，并把我引向原始论文的这一或那句话。 这是说“理论”是好的，即使“实践”有缺陷。 “ 是的，共产主义也有同样的主张， ”有人可能会争辩。

The debate of whether a practice is RESTful or not has become a running gag in the web development ecosystem. However, for the sake of intellectual honesty, it was actually interesting to come back to the most authoritative definition of REST™ as given by the dissertation #1 and related articles. It’s at least to understand how this hype started, and what can be saved from it all.

关于一种实践是否是RESTful的争论已经成为Web开发生态系统中的一个难题。 但是，出于知识上的诚实，回到论文＃1和相关文章给出的最权威的REST™定义实际上很有趣。 至少要了解这种炒作是如何开始的，以及可以从中全部节省下来的内容。

I hope the summaries below will be deemed faithful enough to the originals. If not, I welcome your feedback on other “misconceptions” they might contain.

我希望下面的摘要对原著足够忠实。 如果没有，我欢迎您对它们可能包含的其他“误解”提供反馈。

原始的REST™是什么？ (What is the Original REST™ anyway?)

Roy Fielding’s dissertation, published in 2000, is naturally long (180 pages), so it’s probably not widely read among web developers.

罗伊·菲尔丁(Roy Fielding)的论文发表于2000年，自然很长(180页)，因此在Web开发人员中可能没有广泛阅读。

Here is a breakdown of its content. As an alternative, you can also read the Introduction and Conclusion chapters of said dissertation.

这是其内容的细分。 或者，您也可以阅读该论文的“简介”和“结论”章节。

• Chapter 1 defines architecture-related terms like elements, components, properties, styles, patterns, and so on.
  第1章定义了与架构相关的术语，例如元素，组件，属性，样式，模式等。
• Chapter 2 lists the key properties for a network-based architecture: user-perceived performance, network efficiency, scalability, modifiability, visibility, and reliability.
  第2章列出了基于网络的体系结构的关键属性：用户感知的性能，网络效率，可伸缩性，可修改性，可见性和可靠性。
• Chapter 3 classifies existing architectural styles (Pipe and Filter, Cache, Client-Server, Code on Demand), and shows their pros and cons regarding the key properties above.
  第3章对现有架构样式(管道和过滤器，缓存，客户端-服务器，按需代码)进行了分类，并说明了它们在上述关键属性方面的优缺点。
• Chapter 4 summarizes the requirements of the World Wide Web architecture (Low Entry Barrier, Extensibility, Distributed Hypermedia, Anarchic Scalability and so on), and explains why a dedicated architectural style is needed to guide its development, especially to evaluate proposed extensions before they are deployed.
  第4章总结了万维网体系结构的要求(低进入屏障，可扩展性，分布式超媒体，无政府可伸缩性等)，并说明了为什么需要专用的体系结构样式来指导其开发，尤其是在评估提议的扩展之前，部署。
• Chapter 5 presents the REST architectural style: the existing styles from which it derives, its architectural elements (Resources and their Identifiers, Representations, Connectors, Components, and so on), and how all this works together regarding processes and data.
  第5章介绍了REST的体系结构样式：它衍生自的现有样式，其体系结构元素(资源及其标识符，表示形式，连接器，组件等)，以及所有这些如何在流程和数据上协同工作。
• Chapter 6 gives an experience feedback of how REST was used to guide the development of Web protocol standards (URIs, HTTP and its numerous features and extensions), where it failed to be applied (cookies, mixing of different concerns in headers, user IDs in URIs, and so on), and the architectural lessons to be learned from the modern Web architecture.
  第6章提供了经验反馈，说明如何使用REST指导Web协议标准(URI，HTTP及其众多功能和扩展)的开发，而该标准未能在其中应用(Cookie，标头中混合的各种问题，用户ID)。 URI等)，以及从现代Web架构中学习的架构课程。

What do we get from this dissertation, apart from the usual REST constraints?

除了常见的REST约束 ，我们还能从本文中学到什么？

First, as expected from the introduction of an “architectural style,” it says almost nothing about HTTP methods, schemas, error handling, versioning, and all these concrete subjects which shape real-world webservices. That’s why hundreds of contradicting opinions have flowed to fill the hole, and that’s why it’s weird to sometimes hear that REST is “precisely specified” by this dissertation.

首先，正如引入“建筑风格”所期望的那样，它几乎没有涉及HTTP方法，模式，错误处理，版本控制以及构成现实Web服务的所有这些具体主题。 这就是为什么数百种矛盾的观点涌出填补了这个空白的原因，这就是为什么有时听到REST被本文“ 精确指定 ”的原因很奇怪。

Second, REST was formalized to give a theoretical backbone to the development of the World Wide Web. It mixes lots of existing architectural styles, and inherits from their benefits and drawbacks, for the purpose of designing an Internet-scale distributed hypermedia system.

其次，REST被正式化，为万维网的发展提供了理论基础。 它混合了许多现有的体系结构样式，并从它们的优缺点中继承下来，目的是设计一个Internet规模的分布式超媒体系统 。

And it works.

而且有效。

• On the web, we are happy that all webpages speak HTTP, display themselves with a GET, and handle forms with GET or POST [Uniform Interface]
  在网络上，我们很高兴所有网页都使用HTTP，使用GET进行显示，并使用GET或POST处理表单[统一界面]
• On the web, we’re happy that our browser understands hundreds of content types (HTML, images, CSS, fonts, Javascript, RSS…), and handles them according to numerous built-in rules (caching, display, security…) [Self-Descriptive Messages]
  在网络上，我们很高兴我们的浏览器能够理解数百种内容类型(HTML，图像，CSS，字体，Javascript，RSS…)，并根据众多内置规则(缓存，显示，安全性……)来处理它们。自描述消息]
• On the web, we’re happy to have in-browser caching, content delivery networks, and other forms of shared caches, helping to speed up loading time and absorb traffic peaks (like “Slashdot effects”). Even though a quick ctrl+F5 is sometimes needed to fix weird behaviors of webpages. [Layered System & Caching]
  在网络上，我们很高兴拥有浏览器内缓存，内容交付网络以及其他形式的共享缓存，从而有助于加快加载时间并吸收流量峰值(例如“ Slashdot效果”)。 即使有时需要快速按Ctrl + F5来修复网页的怪异行为。 [分层系统和缓存]
• On the web, we’re happy that proxies and firewalls understand web protocols, and let them flow, while blocking dubious TCP/UDP connections. [Visibility]
  在网络上，我们很高兴代理和防火墙能够理解网络协议，并在阻止可疑的TCP / UDP连接的同时让它们流通。 [能见度]
• On the web, we’re happy that scripts can be delivered by the server for each page, since browsers have, by themselves, no clue about how to add dynamics to provided HTML [Code-On-Demand]
  在网络上，我们很高兴服务器可以为每个页面提供脚本，因为浏览器本身不知道如何为所提供HTML添加动态功能[按需编码]

One point evoked but not detailed in the dissertation is “Hypermedia As The Engine Of Application State” (HATEOAS). In complementary articles, Roy Fielding explained the concept of “hypermedia controls,” also called “affordances:” some kinds of glorified links, advertising to the client “what it can do next.” And he declared (a little late?) that these are not mere options, but that HATEOAS is at the very core of REST.

在本文中， 值得一提的是，“ 超媒体作为应用程序状态的引擎 ” (HATEOAS)。 在补充文章中，罗伊·菲尔丁(Roy Fielding)解释了“ 超媒体控件 ”的概念，也称为“ 赠品： ”某些美化的链接，向客户宣传“下一步可以做什么”。 他宣布(有点晚了吗？)这些不仅仅是选项，而是HATEOAS是REST的核心。

When I say Hypertext, I mean … The simultaneous presentation of information and controls such that the information becomes the affordance through which the user obtains choices and selects actions. Hypertext does not need to be HTML on a browser: machines can follow links when they understand the data format and relationship types (source).

当我说“超文本”时，我的意思是……信息和控件的同时呈现，从而使信息成为用户用来选择和选择动作的能力。 超文本在浏览器上不需要是HTML：机器了解数据格式和关系类型( 源 )后就可以跟随链接。

Information and actions, displayed up to a user through a self-documenting format of awesomeness, with a selection of links that turn a well-tuned client into a crawler instead of just being a CRUD exchange… well that’s the whole point of REST (source).

信息和操作通过令人敬畏的自我记录格式显示给用户，并带有链接的选择，这些链接将经过良好调整的客户端转变为搜寻器，而不仅仅是CRUD交换……这就是REST的全部意义( 来源) )。

Naturally, that is where I have to explain why “hypermedia as the engine of application state” is a REST constraint. Not an option. Not an ideal. Hypermedia is a constraint. As in, you either do it or you aren’t doing REST (source).

自然，这就是我必须解释为什么“作为应用程序状态引擎的超媒体”是REST约束的原因。 别无选择。 不理想。 超媒体是一个约束。 在这种情况下，您要么做，要么就不做REST( source )。

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 (i.e., expected to be understood by any client that might use the API) (source).

一个REST API应该超出了最初的URI(书签)的先验知识输入，并设置标准化的媒体类型是适合于目标受众(即预计到可能使用API的任何客户端可以理解)( 来源 )。

Regarding this aspect too, the Web seems RESTful. From the homepage of a website, users and webspiders are able to navigate it effortlessly, and handle related medias (images, stylesheets, scripts, and so on) that are discovered along the way. Although URLs change over time and forms are added and removed, websites don’t need version numbers, and it’s fine.

同样在这方面，Web似乎是RESTful的。 在网站的主页上，用户和webspiders可以轻松浏览它，并处理在此过程中发现的相关媒体(图像，样式表，脚本等)。 尽管URL随时间变化并且添加和删除了表单，但网站不需要版本号，这很好。

We thus see that the original REST™ is a powerful architectural style, providing big control to servers over their clients, and offering a crawlable ecosystem of editable hypermedia.

因此，我们看到原始的REST™是一种强大的体系结构样式，可以为服务器提供对其客户端的大量控制，并提供可编辑的超媒体的可爬网生态系统。

Now, what about your APIs? Do they aim at being “Internet-scale distributed hypermedia systems,” too?

现在，您的API呢？ 他们是否也旨在成为“ 互联网规模的分布式超媒体系统 ”？

危险的(通常)不必要的圣杯 (The hazardous and (often) unnecessary Holy Grail)

You might have heard about the Richardson Maturity Model. It evaluates the level of RESTfulness of your API, depending on whether it uses proper resources (Level 1), verbs (Level 2), and hypermedia controls (Level 3). This model might give you the feeling that some “RESTish” APIs of yours are meant to evolve on these “steps toward the glory of REST” (as Martin Fowler describes it). Bad news, this most probably won’t occur.

您可能已经听说过Richardson成熟度模型 。 它评估API的RESTful级别，具体取决于它是否使用适当的资源(级别1)，动词(级别2)和超媒体控件(级别3)。 该模型可能会给您一种感觉，您的某些“ RESTish” API打算在这些“ 迈向REST荣耀的步骤 ”上发展(正如Martin Fowler所描述的那样)。 坏消息，这很可能不会发生。

Yes, you can fake RESTfulness by mapping your server functions to Resource URLs. Yes, you can fake it further by mapping your operations to the closest HTTP verbs. But when it’s time to reach the final level, to really have a self-descriptive, crawlable, hypermedia-driven application, you’ll have to realize the harsh truth: your API is not RESTful, it has never been, and it never will be. It actually has less chances to attain “True RESTfulness” than a slug has to become a butterfly.

是的，您可以通过将服务器功能映射到资源URL来伪造RESTful。 是的，您可以通过将操作映射到最接近的HTTP动词来进一步伪造它。 但是，到了达到最终水平，真正拥有一个可自我描述，可爬网，超媒体驱动的应用程序的时候，您就必须意识到一个残酷的事实：您的API不是RESTful，它从未使用过，而且从未使用过。是。 实际上，获得“真正的RESTful”的机会要比than成蝴蝶的机会要少。

Remember the quotes from Roy Fielding in the previous section? His definition of REST is all about HATEOAS. But it’s an extremely ambitious statement.

还记得上一节中Roy Fielding的话吗？ 他对REST的定义完全与HATEOAS有关。 但这是一个非常雄心勃勃的声明。

It means you should forget meaningless MIME types like “text/xml” or “text/json,” and use specific content types, backed by contracts, and recognizable by API consumers. It means that unless a full-fledged RESTful protocol already exists for your precise use case, you’ll have to write RFC/IETF-style drafts to describe the semantics of your specific content types. You’ll have to design a crawler-enabled hypermedia system, and specify the meaning of its miscellaneous “affordances.” And you’ll probably have to provide client implementations to your customers, in their own programming languages, since they have other things to do than follow such herculean endeavors.

这意味着您应该忘记无意义的MIME类型(例如“ text / xml”或“ text / json”)，并使用特定的内容类型(由合同支持并由API使用者识别)。 这意味着，除非针对您的精确用例已经存在完整的RESTful协议，否则您将不得不编写RFC / IETF样式的草稿来描述特定内容类型的语义。 您必须设计一个启用搜寻器的超媒体系统，并指定其杂项“负担”的含义。 而且，您可能必须以客户自己的编程语言向客户提供客户实施，因为他们除了遵循如此艰苦的努力外还要做其他事情。

All this is huge specification and implementation work. For rather light benefits. And worrisome drawbacks.

所有这些都是巨大的规范和实现工作。 对于相当轻的好处。 和令人担忧的弊端。

Yes, this enables server-side developers to keep control of their URL structure without redirections (today I’ll rename “users/” to “accounts/” — it’s smoother), but at what cost? Unless you constantly generate new URLs to prevent it, I bet your API consumers will hardcode URLs anyway, to avoid this extra layer of complexity (recognition of affordances, URL traversal caching etc.)

是的，这使服务器端开发人员无需重定向即可控制其URL结构( 今天，我将“ users /”重命名为“ accounts /”，这更顺畅 )，但是要花多少钱？ 除非您不断生成新的URL来防止这种情况发生，否则我敢打赌，您的API使用者无论如何都会对URL进行硬编码，以避免这种额外的复杂性(识别能力，URL遍历缓存等)。

Yes, this enables the server to control available actions, when the end consumer is a human. But what about User eXperience? The arbitrary showing and masking of affordances by the server is a scary concept. When a “delete” button is missing on a SPA, I want to know why. And if I ask my REST-crawler program to create “this” resource, I’d rather have him fail with a proper remote error message, than say “sorry, couldn’t find the affordance for that.” Actions can be prevented by security rules, missing dependencies, concurrent tasks, and other issues. We have the right to know what’s going on, and “affordances,” in their current form, miss this crucial feature.

是的，当最终用户是人类时，这使服务器能够控制可用操作。 但是，用户体验如何？ 服务器随意显示和掩盖能力是一个可怕的概念。 当SPA上缺少“删除”按钮时，我想知道为什么。 而且，如果我要求我的REST爬虫程序创建“此”资源，我宁愿让他失败并显示一条正确的远程错误消息，而不是说“ 对不起，无法为此提供帮助。” ”可以通过安全规则，缺少依赖项，并发任务和其他问题来阻止操作。 我们有权知道发生了什么，并且以当前形式存在的“负担”错过了这一关键功能。

Also, what about machine-to-machine interactions? If API evolvability is key, how does the consumer program understand new fields and new affordances? Roy Fielding answers “That is where code-on-demand shines.” No way. No way you’re dynamically injecting your remote code into my Python program anytime soon.

另外，机器对机器的交互又如何呢？ 如果API的可扩展性很关键，那么消费者程序如何理解新的领域和新的能力？ Roy Fielding 回答： “ 这就是按需编码的亮点。 “ 没门。 您不可能很快将动态代码远程注入到我的Python程序中。

After reading hundreds of pages on the REST/HATEOAS subject, I’ve rarely been so unimpressed. Reaching LEVEL 3 of RESTfulness was supposed to be an epiphany. I rather have the deep feeling that the remedy is worse than the disease.

在阅读了数百篇有关REST / HATEOAS主题的文章之后，我很少对它如此印象深刻。 达到RESTfulness的级别3应该是一个顿悟。 我宁愿对这种疗法比疾病更深刻的感觉。

Now, some people argue that Roy Fielding is pushing the concept too far, that “lightweight REST” (i.e “Richardson Maturity Level 2,” without Hypermedia Controls) is the real goal to head for.

现在，有人认为罗伊·菲尔丁(Roy Fielding)将该概念推的太远了，真正的目标是“ 轻量级的REST ”(即“没有超级媒体控件的理查森成熟度2级”)。

But still, I bet you actually do not need any of this.

但是，我敢打赌，您实际上不需要任何这些。

• You (most probably) do not want code-on-demand. You want your clients to read your specs, and call your API precisely as you (and they) intend it.
  您(最有可能)不想按需编码。 您希望客户阅读您的规范，并按照您(和他们)的意愿准确地调用您的API。
• You (most probably) do not want network-level visibility. On the contrary, you want as much TLS encryption as possible.
  您(很可能)不希望获得网络级的可见性。 相反，您想要尽可能多的TLS加密。
• You (most probably) do not want shared caches or client-side caching. On the contrary, remote caches are amongst your worst enemies. And if your API consumers are not browsers, they typically ignore caching headers anyway.
  您(很可能)不希望共享缓存或客户端缓存。 相反，远程缓存是您最大的敌人之一。 而且，如果您的API使用者不是浏览器，他们通常还是会忽略缓存头。
• You (most probably) can do without content negotiation, and other HTTP features more or less bundled with REST best practices (you know, for Representation versus Resource). Every up-to-date language can understand formats like Xml and Json.
  您(很可能)可以不进行内容协商，而将其他HTTP功能或多或少与REST最佳实践捆绑在一起(您知道，对于表示形式还是资源)。 每种最新的语言都可以理解Xml和Json等格式。
• You (most probably) do not want to expose Resources for CRUD operations, and use these awkward men-in-the-middle to trigger actual operations in your applications.
  您(最有可能)不想公开用于CRUD操作的资源，而是使用这些笨拙的中间人来触发应用程序中的实际操作。

All you (most probably) want is to expose a bunch of your server-side functionalities to remote browsers or servers. In a quick, elegant, robust, way.

您(最可能)想要做的就是将一堆服务器端功能公开给远程浏览器或服务器。 快速，优雅，强大。

Your API (most probably) screams “RPC”. And in this case, not even a skyscraper-sized shoehorn will allow it to fit into the very ambitious, but rarely relevant, REST Architectural Style.

您的API(很有可能)会尖叫“ RPC”。 在这种情况下，即使是摩天大楼大小的鞋拔也无法使其适应雄心勃勃但很少相关的REST建筑风格。

For sure, you might need this or that property of HTTP. For example, you might want to use the GET method and different URIs for your Ajax-originated read-only operations to benefit from browser-side caching. Or you might want to expose your database as CRUD-over-HTTP to leverage generic implementations (like Active Record style clients for JsonAPI protocol).

当然，您可能需要HTTP的该属性。 例如，您可能想对源自Ajax的只读操作使用GET方法和不同的URI，以从浏览器端缓存中受益。 或者，您可能希望将数据库公开为HTTP上的CRUD，以利用通用实现(例如JsonAPI协议的Active Record样式客户端)。

But whatever your needs are, life is short. You do not need to start from an abstract “set of guidelines” like REST constraints. You had better seek a turnkey protocol, matching the needs you really have.

但是，无论您的需求是什么， 生命都是短暂的 。 您无需从REST约束之类的抽象“准则集”开始。 您最好寻求一个交钥匙协议 ，以符合您的实际需求。

There are tons of such solutions (mostly non-RESTful), for lightweight RPC, CRUD, pub/sub, job queues, remote filesystems, data querying/filtering, high performance computing, and bi-directional messaging. Rarely, you’ll have to innovate — add new capabilities to a protocol, or use hybrid approaches. But beginning to “turn verbs into nouns” or following abstract principles as dogmas is the last thing you need to do.

对于轻量级RPC，CRUD，发布/订阅，作业队列，远程文件系统，数据查询/过滤，高性能计算和双向消息传递，有很多这样的解决方案(主要是非RESTful)。 很少，您必须进行创新-为协议添加新功能，或使用混合方法。 但是，开始将动词变成名词或遵循抽象原则作为教条是您要做的最后一件事。

Please note, by the way, that CRUD can also be done as a mere subset of RPC. Webservices are usually not coded in C language anymore, so if you see one more wanderer arguing that “it’s awful to have to code so many boilerplate CRUD functions”, please enlighten them with this high-technology API.

请注意，顺便说一句，CRUD也可以仅作为RPC的子集来完成。 Web服务通常不再使用C语言编写代码，因此，如果您再看到一个流浪者争辩说“ 必须编写这么多样板CRUD函数 ， 那真是太糟糕了 ”，请使用此高科技API来启发他们。

create(type, **params) -> id
retrieve(type, id, **params)
update(type, id, **params)
delete(type, id, **params)

Along your (most probably) RESTless way, you’ll meet dozens of adamant speeches, claiming that only REST can grant you scalability and longevity. There is little need to disprove what has never been proven. All I can judge, from personal experience, is that:

在您(最可能是)不使用REST的方式中，您会遇到许多坚定的演讲，他们声称只有REST才能为您提供可伸缩性和持久性。 几乎没有必要反驳从未得到证明的东西。 根据我的个人经验，我可以判断的是：

• A well configured database and a simple server-side cache are enough for 99% of webservices; an old wisdom says premature optimization is the root of all evil.

  配置完善的数据库和简单的服务器端缓存足以满足99％的Web服务； 古老的智慧说过早的优化是万恶之源 。

• Services evolve continuously. Whether it means a new parameter in a remote procedure or a new field in a resource representation, it doesn’t matter much. And the API Evolution concept is, as far as I’ve read, nothing but plain old wisdom from software development: don’t make breaking changes until absolutely needed, and use compatibility layers to help everyone move forward at a sane pace.

  服务不断发展。 无论是在远程过程中表示新参数还是在资源表示中表示新字段，都无关紧要。 就我所知， API Evolution的概念不过是软件开发中的古老经验：在绝对需要之前，不要做出重大更改，并使用兼容性层来帮助每个人以稳健的步伐前进。

• Even if you design your API awkwardly, it will certainly be dead loooong before it has real compatibility issues. Maybe not because its purpose has become irrelevant, and maybe not because of crushing competitors, but likely because of changes-of-mind in your marketing department.
  即使您笨拙地设计您的API，在出现真正的兼容性问题之前，它肯定也无法解决。 可能不是因为它的目的变得无关紧要，也许不是因为粉碎竞争对手，而是因为您的营销部门的想法改变了。
• With the time spent to properly integrate most REST-style APIs, one could implement several successive versions of corresponding lightweight RPC webservices. Let’s remain pragmatic.
  随着花时间正确集成大多数REST风格的API，人们可以实现相应轻量级RPC Web服务的多个连续版本。 让我们保持务实。
• When a tech startup, with a life expectancy below 2 years, spends one third of its time writing REST(ish) boilerplate, its CTO might deserve to be slapped with a large trout. Good programming practices and cheap workarounds are all they need, until they reach the state where scalability becomes a matter worth thinking about and spending money on.
  当一家预期寿命低于2年的科技创业公司花费其三分之一的时间编写REST(ish)样板时，其CTO也许应该被大鳟鱼打败。 他们只需要良好的编程习惯和廉价的解决方法，直到它们达到可伸缩性成为值得考虑并花钱的状态。

Most importantly, please give up this Holy Grail Quest called “HATEOAS,” unless you’re part of the few Knights in the world concerned by this Mission.

最重要的是，除非您是与此任务相关的世界上少数骑士中的一员，否则请放弃这个名为“ HATEOAS”的圣杯任务。

REST/HATEOS is for specific data-centric APIs: those which are naturally CRUD, those which are consumed via ActiveRecord or DataMapper patterns in your favorite languages, those which do not have tons of subtle constraints and side-effects between the fields of a model, and those meant to be explored by humans (currently the only entities in the universe able to understand what this newly appeared “billing contact email” field means).

REST / HATEOS适用于特定的以数据为中心的API：那些自然是CRUD的API，那些通过您喜欢的语言通过ActiveRecord或DataMapper模式使用的API，那些在模型字段之间没有大量微妙的约束和副作用的API ，以及将由人类探索的对象(当前，宇宙中唯一能够理解此新出现的“ 帐单联系人电子邮件 ”字段含义的实体)。

Otherwise, you’ll end up with the awkwardness of RESTish APIs, but with an extra stack of complications.

否则，您最终将面临RESTish API的尴尬，但会带来额外的麻烦。

One relevant use case for HATEOS would be a generic “Database Admin Protocol,” allowing any server to drive a same generic Single Page Application through the structure of its (SQL or no-SQL) database: navigation between tables and record pages, autogenerated forms for each schema, dynamic create/edit/delete buttons, and so on.

HATEOS的一个相关用例是通用的“数据库管理协议”，它允许任何服务器通过其(SQL或非SQL)数据库的结构来驱动相同的通用单页应用程序：表和记录页之间的导航，自动生成的表单对于每个模式，动态创建/编辑/删除按钮，等等。

In similar fashion, an API dedicated to browsing and editing documentation, or exploring/pulling/pushing a Version Control System, would lend itself well to a REST architectural style. But these are far, very far, from what most webservices are built for. And if Github switched from REST to GraphQL for its API, it’s a hint that the benefits claimed by REST were just not enough.

以类似的方式，专用于浏览和编辑文档或探究/拉动/推动版本控制系统的API会很适合REST体系结构样式。 但是，这些与大多数Web服务的构建目标相去甚远。 而且，如果Github为其API 从REST切换到GraphQL ，则表明REST声称的好处还不够 。

哪里出错了？ (Where did it go wrong?)

So here we are. REST/HATEOS is certainly a nicely evolved architectural style, but (imho) only relevant to a tiny fraction of use cases. And now it has spread like cancer over the ecosystem of webservices — mostly under its truncated form called “RESTish APIs” — bringing inadequacy and artificial complexity everywhere. Who is to blame for this awkward situation?

所以我们到了。 REST / HATEOS当然是一种发展良好的架构风格，但是(恕我直言)仅与一小部分用例有关。 现在，它已经像癌症一样在Web服务生态系统中蔓延-大多以其截短的形式称为“ RESTish API”-到处都带来了不足和人为的复杂性。 谁应为这种尴尬局面负责？

• The original dissertation, which didn’t position REST in comparison to other architectures, and remained too vague on its pros and cons?
  原始论文没有将REST与其他体系结构相比定位，并且在其优缺点上仍然过于模糊？
• The REST advocates, who often lost themselves in very subjective (when not contradicting) recommendations, instead of advertising standards and explaining when (not) to use REST?
  REST的倡导者，谁常常迷失于非常主观的(当不矛盾的)建议中，而不是宣传标准并解释何时(不)使用REST？
• The uncountable articles who displayed a false dilemma between SOAP and REST, thus propelling to the stars a winner by default?
  数不清的文章谁在SOAP和REST之间显示了错误的困境，因此默认情况下将明星推向了胜利者？

• The Internet trolls who proclaimed, in about every StackOverflow thread regarding webservices design, “Forget existing protocol XYZ, it’s an extra layer which makes stuffs unmaintainable, all you need is handmade HTTP”?

  互联网上的巨魔们在关于Web服务设计的每个StackOverflow线程中都宣称：“ 忘记现有协议XYZ，这是一个额外的层，使内容无法维护，您所需要的只是手工HTTP ”？

• The buzzword lovers who imposed REST to their teams, without discussing the impacts of this architectural change, without ever asking themselves “but why though?”

  那些对团队强加REST的流行语爱好者，没有讨论过这种架构变化的影响，也没有自问过“ 但是为什么？” ”

• The silent mass of developers, who, like me, have known FOR YEARS that something was deeply wrong, but haven’t blown the whistle?
  沉默寡言的开发人员群体，像我一样，在过去的几年中都知道有些事情是严重错误的，但是还没有吹响？

Yup. I guess it’s a mix of all these.

对。 我想这是所有这些的混合。

The cruel irony of this story is that the original dissertation itself warned about bandwagon jumping and improper architectural choices:

这个故事的残酷讽刺是， 原始论文本身就警告了潮流跳跃和不正确的建筑选择：

“How often we see software projects begin with adoption of the latest fad in architectural design, and only later discover whether or not the system requirements call for such an architecture. Design-by-buzzword is a common occurrence. […] The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.”

“ 通常，我们看到软件项目始于采用最新的体系结构设计风尚，直到后来才发现系统要求是否要求这种体系结构。 按关键词设计是一种常见的情况。 […] REST接口被设计为对于大颗粒超媒体数据传输是高效的，针对Web的常见情况进行了优化，但是导致的接口对于其他形式的体系结构交互不是最佳的。 ”

Some good news, however, is that REST has paved the way for other protocols, like GraphQL and HTTP2. And its use of advanced HTTP features is an inspiration for other architectures. We owe it at least that.

不过，有些好消息是REST为其他协议(例如GraphQL和HTTP2)铺平了道路。 它对高级HTTP功能的使用为其他体系结构提供了灵感。 我们至少应该欠它。

如果您真的需要RESTify怎么办？ (What if you *really* have to RESTify?)

For lots of reasons (like corporate hierarchy, or really needing CRUD with HTTP caching), you might have to go for REST. With or without HATEOAS.

由于许多原因(例如公司层次结构，或者确实需要使用HTTP缓存的CRUD)，您可能必须使用REST。 有或没有HATEOAS。

In my previous article, I suggested that industrializing REST clients and servers was a problem without solution. It turns out I was wrong.

在我以前的文章中，我建议工业化REST客户端和服务器是没有解决方案的问题。 原来我错了 。

Here is an non-exhaustive list of REST-related “standards”, grabbed from the inputs of various commenters. You can find a lot more on Phil Sturgeon’s new standards.rest listing.

以下是从各种评论者的输入中获取的与REST相关的“标准”的详尽列表。 您可以在Phil Sturgeon的新standard.rest列表中找到更多信息。

• To specify semantics of PATCH: JSON Patch, JSON Merge Patch
  要指定PATCH的语义：JSON补丁，JSON合并补丁
• To specify interface contracts: JSON Schema, API Blueprint, OpenAPI (formerly Swagger), RAML, GraphQL Types, XML Schema
  要指定接口协定：JSON模式，API蓝图，OpenAPI(以前为Swagger)，RAML，GraphQL类型，XML模式
• To serialize results and/or errors in responses: JSend format, RFC7807 (Problem Details for HTTP APIs), Sparse fieldsets (restricting the fields to return), Compound documents (including related resources)
  序列化结果和/或响应中的错误：JSend格式，RFC7807(HTTP API的问题详细信息)，稀疏字段集(限制字段返回)，复合文档(包括相关资源)
• Protocols with hypermedia controls: JSON Hyper-Schema (IETF Draft), JSON Hypertext Application Language or “HAL” (IETF Draft), Json-API, OData, Mason, Hydra/JSON-LD, JSON SIREN
  具有超媒体控件的协议：JSON超模式(IETF草案)，JSON超文本应用语言或“ HAL”(IETF草案)，Json-API，OData，Mason，Hydra / JSON-LD，JSON SIREN

These are indeed quite a good number of possibilities. A combinatorial explosion of possibilities, since many of them only take care of a small portion of the protocol. These efforts at standardizing are welcome, although they are somehow late: the most RESTful ones (for hypermedia) are, nearly 18 years after Roy Fielding’s dissertation, still drafts.

这些确实有很多可能性。 可能性的组合爆炸式增长，因为其中许多仅处理协议的一小部分。 这些标准化工作受到欢迎，尽管有些迟了：Roy Fielding论文发表将近18年之后，对于RESTful(用于超媒体)的工作仍在起草中。

Do you know why I didn’t cite any of them in my previous rant?

您知道为什么我以前的讲话中都没有引用吗？

Because during all those years spent integrating the APIs of big companies (think Google, Microsoft, Oracle, Dropbox, Spotify, and others), as well as that of smaller enterprise, NOT ONCE have I met any of these “standards”, neither explicitly nor implicitly. Maybe it’s because I was unlucky. Maybe it’s because they are rarely used.

因为在所有这些年中，花了很多时间来集成大型公司(例如Google，Microsoft，Oracle，Dropbox，Spotify等)的API，以及小型企业的API，所以我一次都没有满足任何这些“标准”，没有一个明确地也不隐含。 也许是因为我倒霉。 也许是因为它们很少使用。

From my point of view, this lack of visible standardization has to do with the original sin of the REST: for some reason, it came with a very strong anti-standards mindset, with an obscurantist “all you need is love and HTTP” philosophy. So even the most talented developers felt the urge to specify their own half-baked protocol, in their corner, oblivious to thousands of others who had already done the same.

从我的角度来看，这种缺乏可见性的标准化与REST的初衷有关 ：由于某种原因，它带有非常强烈的反标准思维方式，并且带有晦涩的“只需要爱和HTTP ”的哲学。 因此，即使是最有才华的开发人员也渴望在角落里指定自己的半熟协议，而忽略了成千上万已经这样做的其他人。

In your case, naturally, the least harm will be to use existing standards and libraries. Preferably full-fledged protocols, rather than LEGO-style assemblies of RFCs.

对于您而言，自然而然地，危害最小的是使用现有的标准和库。 最好是成熟的协议 ，而不是RFC的LEGO样式的程序集。

I shall warn you, though. Here be dragons, too.

不过，我会警告您。 这里也有龙。

Sometimes, the devil is in the details. An old wisdom in computer sciences states that errors shall not go silent. That’s why it’s good practice to keep the format of objects consistent: some of their fields might be nullified, but they are present at all time anyway (unless asked otherwise by the client). That’s the best way to prevent false negatives (due to typos), and to avoid random breakages in strict clients if the quantic property of these fields was (as often) not properly documented.

有时，细节决定成败。 计算机科学的古老观点指出，错误不会消失。 这就是为什么要使对象的格式保持一致是一个好习惯的原因：它们的某些字段可能会为空，但无论如何它们始终存在(除非客户端另有要求)。 这是防止误报 (由于拼写错误)和避免严格客户中随机中断的最佳方法， 前提是这些字段的数量属性(经常)没有正确记录。

I thought that this idea naturally applied to REST representations, too. Too bad: standards like JSON Merge Patch force you to delete remote fields instead of nullifying them. These tiny but apocalypse-triggering details are especially inappropriate in a philosophy which claims to “help client and server evolve independently.”

我认为这个想法自然也适用于REST表示。 太糟糕了： JSON合并补丁程序之类的标准迫使您删除远程字段而不是使它们无效。 这些微小但启示深刻的细节在一种声称“ 帮助客户端和服务器独立发展的哲学”中尤其不合适。 ”

Sometimes, the devil is elephant-sized. Ever heard about this OpenAPI (formerly Swagger), one of the most ambitious REST standards? The idea is to describe your API in a specification file, with endpoints and schemas, and use OpenAPI tools to industrialize the creation of both client and server. It sounds nice, doesn’t it?

有时，魔鬼是大象大小的。 是否听说过最雄心勃勃的REST标准之一OpenAPI(以前称为Swagger)？ 想法是在规范文件中使用端点和架构描述您的API，并使用OpenAPI工具对客户端和服务器的创建进行工业化。 听起来不错，不是吗？

Here is an example json interface spec, for the Kubernetes API. Yes, Json schemas are by nature extremely verbose.

这是Kubernetes API的示例json接口规范 。 是的，Json模式本质上非常冗长。

Ok, now here is the corresponding client implementation for Python.

好的，现在这是Python的相应客户端实现 。

As of today, it’s more than 90,000 lines of Python code and comments, automatically generated by OpenAPI. Not just thin wrappers, to benefit from auto-documentation tools and IDE autocompletion. 90,000 lines. More than their json interface spec. What. the. actual. heck.

截至今天，OpenAPI自动生成了超过90,000行Python代码和注释。 不只是薄薄的包装，还可以从自动文档工具和IDE自动补全中受益。 90,000行。 不仅仅是他们的json接口规范。 什么。 的。 实际。 哎呀。

Each language, each framework, has its own idea on how to handle OpenAPI. Some choose hybrid (and elegantly cruft-free) approaches. Some generate a spec file from server code. Most generate tons of boilerplate from said spec file. Sometimes they go farther and generate tests, too.

每种语言，每种框架对于如何处理OpenAPI都有其自己的想法。 有些人选择混合(且优雅无浪费)方法 。 有些从服务器代码生成规范文件。 大多数从所述规格文件中产生大量样板。 有时他们也会走得更远并生成测试。

More tooling and more code generators mean more bugs and harder learning curves… and all that for what? The Kubernetes SDK is exposed to Python as a set of methods. With hardcoded URLs. Again, some RPC-over-CRUD system, considered by many as state-of-the-art RESTfulness, while disregarding HATEOAS. I find all this utterly confusing, and I hope I’m not the only one.

更多的工具和更多的代码生成器意味着更多的bug和更难的学习曲线……所有这些都是为了什么？ Kubernetes SDK作为一组方法公开给Python。 带有硬编码的URL。 同样，有些RPC-over-CRUD系统被许多人认为是最新的RESTful，而无视HATEOAS。 我发现所有这些都令人困惑，我希望我不是唯一的一个。

So be especially wary about REST-related protocols and frameworks you might choose. Some are handy and efficient, but some make REST look more and more like the new SOAP.

因此，请特别注意您可能选择的与REST相关的协议和框架。 有些既方便又高效，但是有些使REST越来越像新的SOAP。

TL; DR (TL;DR)

The original REST™ is like rocket engineering: exciting, but very specific, quite complex, and rather harmful unless you precisely know what you’re doing.

原始的REST™就像火箭工程一样：令人兴奋，但非常具体，非常复杂，而且非常有害，除非您确切地知道自己在做什么。

RESTish APIs are more affordable, but be sure that you‘ll benefit from them, since it’s rarely the case. To quote a simple rule of thumb from Phil Sturgeon:

RESTish API更便宜，但请确保您会从中受益，因为这种情况很少见。 引用Phil Sturgeon的简单经验法则：

“If an API is mostly actions, maybe it should be RPC. If an API is mostly CRUD and is manipulating related data, maybe it should be REST”.

“ 如果API主要是操作，则可能应该是RPC。 如果一个API主要是CRUD并且正在处理相关数据，那么它应该是REST ”。

Lots of REST(ish) “standards” exist, so no need to ever specify one from scratch. But whatever your needs are, beware of buzzwords, use the right tool for the right job (REST and RPC are only two amongst hundreds), and most importantly, KISS. I bet you’d have more success using a generic JsonAPI client and validating it against a real preprod server, than spending days generating tons of boilerplate OpenAPI code — only to discover later that it doesn’t actually match the remote side because of bugs or other incompatibilities.

存在许多REST(ish)“标准”，因此无需从头开始指定一个。 但是无论您需要什么，请提防流行语，使用正确的工具完成正确的工作(REST和RPC仅是数百种中的两种)，最重要的是KISS 。 我敢打赌，与花几天时间生成大量样板的OpenAPI代码相比，使用通用JsonAPI客户端并针对真正的preprod服务器进行验证会获得更大的成功—后来才发现由于错误或错误，它实际上与远程端不匹配其他不兼容性。

The same goes for other architectures, by the way: you’ll probably save time using simple JsonRPC or JsonWSP protocols, instead of generating boilerplate with gRPC, only to later realize that this shiny protocol hasn’t even specified how to report application-level errors.

顺便说一句，其他架构也是如此：您可能会使用简单的JsonRPC或JsonWSP协议节省时间，而不是使用gRPC生成样板，只是后来才意识到，这个闪亮的协议甚至没有指定如何报告应用程序级别错误。

结语 (Epilogue)

REST is a difficult subject to talk about. There are lots of plot holes in the founding dissertation, lots of conflicting definitions, lots of contradicting opinions on how to do this or that right, lots of unjustified hypes and disgraces, lots of (underused and partial) standards… and very few real life examples of HATEOAS APIs (most links I’ve crossed were dead, so much for the “lasting decades”).

REST是一个很难谈论的话题。 开篇论文中有很多积淀Kong，很多矛盾的定义，关于如何做到这一点或那项权利的观点相互矛盾，很多无理的炒作和贬低，很多(未充分使用和部分使用)标准，以及现实生活中很少HATEOAS API的示例(我经过的大多数链接都已失效，在“ 持续数十年之内 ”如此之多)。

But I hope that this analysis has clarified a bit the different “RESTs” people are talking about, and that it will spare you some of the obscene amount of time I had to spend just to somehow understand what the Original REST™ was meant to be.

但是，我希望这种分析能够澄清人们在谈论的不同“ REST”，并且可以让您节省一些我不得不花费的淫秽时间，以便以某种方式了解原始REST™的含义。 。

At the very least, you now have a new weapon in your bag. The next time your boss wants you to expose some server operations as REST webservices, just ask:

至少，现在您的书包中有一件新武器。 下次老板希望您将某些服务器操作公开为REST Web服务时，只需询问：

For this API, do we really need to follow a composite architectural style meant for Internet-scale distributed hypermedia systems?

对于此API，我们是否真的需要遵循适用于Internet规模的分布式超媒体系统的复合体系结构样式？

The expression on his face will be your answer.

他脸上的表情将是你的答案。

Please leave your comments below. And here are past comments about this article on Medium: https://medium.com/p/21c59d243438/responses/show

请在下方留下你的意见。 以下是有关本文在媒体上的过往评论： https ： //medium.com/p/21c59d243438/responses/show

翻译自: https://www.freecodecamp.org/news/follow-up-to-rest-is-the-new-soap-the-origins-of-rest-21c59d243438/

soap rest