mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
CanYellow
GitHub
parent
13d4dba125
commit
b4a418a90a
@ -1,125 +0,0 @@
|
|||||||
[#]: collector: (lujun9972)
|
|
||||||
[#]: translator: (CanYellow)
|
|
||||||
[#]: reviewer: ( )
|
|
||||||
[#]: publisher: ( )
|
|
||||||
[#]: url: ( )
|
|
||||||
[#]: subject: (Roy Fielding's Misappropriated REST Dissertation)
|
|
||||||
[#]: via: (https://twobithistory.org/2020/06/28/rest.html)
|
|
||||||
[#]: author: (Two-Bit History https://twobithistory.org)
|
|
||||||
|
|
||||||
Roy Fielding's Misappropriated REST Dissertation
|
|
||||||
======
|
|
||||||
|
|
||||||
RESTful APIs are everywhere. This is funny, because how many people really know what “RESTful” is supposed to mean?
|
|
||||||
|
|
||||||
I think most of us can empathize with [this Hacker News poster][1]:
|
|
||||||
|
|
||||||
> I’ve read several articles about REST, even a bit of the original paper. But I still have quite a vague idea about what it is. I’m beginning to think that nobody knows, that it’s simply a very poorly defined concept.
|
|
||||||
|
|
||||||
I had planned to write a blog post exploring how REST came to be such a dominant paradigm for communication across the internet. I started my research by reading [Roy Fielding’s 2000 dissertation][2], which introduced REST to the world. After reading Fielding’s dissertation, I realized that the much more interesting story here is how Fielding’s ideas came to be so widely misunderstood.
|
|
||||||
|
|
||||||
Many more people know that Fielding’s dissertation is where REST came from than have read the dissertation (fair enough), so misconceptions about what the dissertation actually contains are pervasive.
|
|
||||||
|
|
||||||
The biggest of these misconceptions is that the dissertation directly addresses the problem of building APIs. I had always assumed, as I imagine many people do, that REST was intended from the get-go as an architectural model for web APIs built on top of HTTP. I thought perhaps that there had been some chaotic experimental period where people were building APIs on top of HTTP all wrong, and then Fielding came along and presented REST as the sane way to do things. But the timeline doesn’t make sense here: APIs for web services, in the sense that we know them today, weren’t a thing until a few years after Fielding published his dissertation.
|
|
||||||
|
|
||||||
Fielding’s dissertation (titled “Architectural Styles and the Design of Network-based Software Architectures”) is not about how to build APIs on top of HTTP but rather about HTTP itself. Fielding contributed to the HTTP/1.0 specification and co-authored the HTTP/1.1 specification, which was published in 1999. He was interested in the architectural lessons that could be drawn from the design of the HTTP protocol; his dissertation presents REST as a distillation of the architectural principles that guided the standardization process for HTTP/1.1. Fielding used these principles to make decisions about which proposals to incorporate into HTTP/1.1. For example, he rejected a proposal to batch requests using new `MGET` and `MHEAD` methods because he felt the proposal violated the constraints prescribed by REST, especially the constraint that messages in a REST system should be easy to proxy and cache.[1][3] So HTTP/1.1 was instead designed around persistent connections over which multiple HTTP requests can be sent. (Fielding also felt that cookies are not RESTful because they add state to what should be a stateless system, but their usage was already entrenched.[2][4]) REST, for Fielding, was not a guide to building HTTP-based systems but a guide to extending HTTP.
|
|
||||||
|
|
||||||
This isn’t to say that Fielding doesn’t think REST could be used to build other systems. It’s just that he assumes these other systems will also be “distributed hypermedia systems.” This is another misconception people have about REST: that it is a general architecture you can use for any kind of networked application. But you could sum up the part of the dissertation where Fielding introduces REST as, essentially, “Listen, we just designed HTTP, so if you also find yourself designing a _distributed hypermedia system_ you should use this cool architecture we worked out called REST to make things easier.” It’s not obvious why Fielding thinks anyone would ever attempt to build such a thing given that the web already exists; perhaps in 2000 it seemed like there was room for more than one distributed hypermedia system in the world. Anyway, Fielding makes clear that REST is intended as a solution for the scalability and consistency problems that arise when trying to connect hypermedia across the internet, _not_ as an architectural model for distributed applications in general.
|
|
||||||
|
|
||||||
We remember Fielding’s dissertation now as the dissertation that introduced REST, but really the dissertation is about how much one-size-fits-all software architectures suck, and how you can better pick a software architecture appropriate for your needs. Only a single chapter of the dissertation is devoted to REST itself; much of the word count is spent on a taxonomy of alternative architectural styles[3][5] that one could use for networked applications. Among these is the Pipe-and-Filter (PF) style, inspired by Unix pipes, along with various refinements of the Client-Server style (CS), such as Layered-Client-Server (LCS), Client-Cache-Stateless-Server (C$SS), and Layered-Client-Cache-Stateless-Server (LC$SS). The acronyms get unwieldy but Fielding’s point is that you can mix and match constraints imposed by existing styles to derive new styles. REST gets derived this way and could instead have been called—but for obvious reasons was not—Uniform-Layered-Code-on-Demand-Client-Cache-Stateless-Server (ULCODC$SS). Fielding establishes this taxonomy to emphasize that different constraints are appropriate for different applications and that this last group of constraints were the ones he felt worked best for HTTP.
|
|
||||||
|
|
||||||
This is the deep, deep irony of REST’s ubiquity today. REST gets blindly used for all sorts of networked applications now, but Fielding originally offered REST as an illustration of how to derive a software architecture tailored to an individual application’s particular needs.
|
|
||||||
|
|
||||||
I struggle to understand how this happened, because Fielding is so explicit about the pitfalls of not letting form follow function. He warns, almost at the very beginning of the dissertation, that “design-by-buzzword is a common occurrence” brought on by a failure to properly appreciate software architecture.[4][6] He picks up this theme again several pages later:
|
|
||||||
|
|
||||||
> Some architectural styles are often portrayed as “silver bullet” solutions for all forms of software. However, a good designer should select a style that matches the needs of a particular problem being solved.[5][7]
|
|
||||||
|
|
||||||
REST itself is an especially poor “silver bullet” solution, because, as Fielding later points out, it incorporates trade-offs that may not be appropriate unless you are building a distributed hypermedia application:
|
|
||||||
|
|
||||||
> REST 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.[6][8]
|
|
||||||
|
|
||||||
Fielding came up with REST because the web posed a thorny problem of “anarchic scalability,” by which Fielding means the need to connect documents in a performant way across organizational and national boundaries. The constraints that REST imposes were carefully chosen to solve this anarchic scalability problem. Web service APIs that are _public-facing_ have to deal with a similar problem, so one can see why REST is relevant there. Yet today it would not be at all surprising to find that an engineering team has built a backend using REST even though the backend only talks to clients that the engineering team has full control over. We have all become the architect in [this Monty Python sketch][9], who designs an apartment building in the style of a slaughterhouse because slaughterhouses are the only thing he has experience building. (Fielding uses a line from this sketch as an epigraph for his dissertation: “Excuse me… did you say ‘knives’?”)
|
|
||||||
|
|
||||||
So, given that Fielding’s dissertation was all about avoiding silver bullet software architectures, how did REST become a de facto standard for web services of every kind?
|
|
||||||
|
|
||||||
My theory is that, in the mid-2000s, the people who were sick of SOAP and wanted to do something else needed their own four-letter acronym.
|
|
||||||
|
|
||||||
I’m only half-joking here. SOAP, or the Simple Object Access Protocol, is a verbose and complicated protocol that you cannot use without first understanding a bunch of interrelated XML specifications. Early web services offered APIs based on SOAP, but, as more and more APIs started being offered in the mid-2000s, software developers burned by SOAP’s complexity migrated away en masse.
|
|
||||||
|
|
||||||
Among this crowd, SOAP inspired contempt. Ruby-on-Rails dropped SOAP support in 2007, leading to this emblematic comment from Rails creator David Heinemeier Hansson: “We feel that SOAP is overly complicated. It’s been taken over by the enterprise people, and when that happens, usually nothing good comes of it.”[7][10] The “enterprise people” wanted everything to be formally specified, but the get-shit-done crowd saw that as a waste of time.
|
|
||||||
|
|
||||||
If the get-shit-done crowd wasn’t going to use SOAP, they still needed some standard way of doing things. Since everyone was using HTTP, and since everyone would keep using HTTP at least as a transport layer because of all the proxying and caching support, the simplest possible thing to do was just rely on HTTP’s existing semantics. So that’s what they did. They could have called their approach Fuck It, Overload HTTP (FIOH), and that would have been an accurate name, as anyone who has ever tried to decide what HTTP status code to return for a business logic error can attest. But that would have seemed recklessly blasé next to all the formal specification work that went into SOAP.
|
|
||||||
|
|
||||||
Luckily, there was this dissertation out there, written by a co-author of the HTTP/1.1 specification, that had something vaguely to do with extending HTTP and could offer FIOH a veneer of academic respectability. So REST was appropriated to give cover for what was really just FIOH.
|
|
||||||
|
|
||||||
I’m not saying that this is exactly how things happened, or that there was an actual conspiracy among irreverent startup types to misappropriate REST, but this story helps me understand how REST became a model for web service APIs when Fielding’s dissertation isn’t about web service APIs at all. Adopting REST’s constraints makes some sense, especially for public-facing APIs that do cross organizational boundaries and thus benefit from REST’s “uniform interface.” That link must have been the kernel of why REST first got mentioned in connection with building APIs on the web. But imagining a separate approach called “FIOH,” that borrowed the “REST” name partly just for marketing reasons, helps me account for the many disparities between what today we know as RESTful APIs and the REST architectural style that Fielding originally described.
|
|
||||||
|
|
||||||
REST purists often complain, for example, that so-called REST APIs aren’t actually REST APIs because they do not use Hypermedia as The Engine of Application State (HATEOAS). Fielding himself [has made this criticism][11]. According to him, a real REST API is supposed to allow you to navigate all its endpoints from a base endpoint by following links. If you think that people are actually out there trying to build REST APIs, then this is a glaring omission—HATEOAS really is fundamental to Fielding’s original conception of REST, especially considering that the “state transfer” in “Representational State Transfer” refers to navigating a state machine using hyperlinks between resources (and not, as many people seem to believe, to transferring resource state over the wire).[8][12] But if you imagine that everyone is just building FIOH APIs and advertising them, with a nudge and a wink, as REST APIs, or slightly more honestly as “RESTful” APIs, then of course HATEOAS is unimportant.
|
|
||||||
|
|
||||||
Similarly, you might be surprised to know that there is nothing in Fielding’s dissertation about which HTTP verb should map to which CRUD action, even though software developers like to argue endlessly about whether using PUT or PATCH to update a resource is more RESTful. Having a standard mapping of HTTP verbs to CRUD actions is a useful thing, but this standard mapping is part of FIOH and not part of REST.
|
|
||||||
|
|
||||||
This is why, rather than saying that nobody understands REST, we should just think of the term “REST” as having been misappropriated. The modern notion of a REST API has historical links to Fielding’s REST architecture, but really the two things are separate. The historical link is good to keep in mind as a guide for when to build a RESTful API. Does your API cross organizational and national boundaries the same way that HTTP needs to? Then building a RESTful API with a predictable, uniform interface might be the right approach. If not, it’s good to remember that Fielding favored having form follow function. Maybe something like GraphQL or even just JSON-RPC would be a better fit for what you are trying to accomplish.
|
|
||||||
|
|
||||||
_If you enjoyed this post, more like it come out every four weeks! Follow [@TwoBitHistory][13] on Twitter or subscribe to the [RSS feed][14] to make sure you know when a new post is out._
|
|
||||||
|
|
||||||
_Previously on TwoBitHistory…_
|
|
||||||
|
|
||||||
> New post is up! I wrote about how to solve differential equations using an analog computer from the '30s mostly made out of gears. As a bonus there's even some stuff in here about how to aim very large artillery pieces.<https://t.co/fwswXymgZa>
|
|
||||||
>
|
|
||||||
> — TwoBitHistory (@TwoBitHistory) [April 6, 2020][15]
|
|
||||||
|
|
||||||
1. Roy Fielding. “Architectural Styles and the Design of Network-based Software Architectures,” 128. 2000. University of California, Irvine, PhD Dissertation, accessed June 28, 2020, <https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation_2up.pdf>. [↩︎][16]
|
|
||||||
|
|
||||||
2. Fielding, 130. [↩︎][17]
|
|
||||||
|
|
||||||
3. Fielding distinguishes between software architectures and software architecture “styles.” REST is an architectural style that has an instantiation in the architecture of HTTP. [↩︎][18]
|
|
||||||
|
|
||||||
4. Fielding, 2. [↩︎][19]
|
|
||||||
|
|
||||||
5. Fielding, 15. [↩︎][20]
|
|
||||||
|
|
||||||
6. Fielding, 82. [↩︎][21]
|
|
||||||
|
|
||||||
7. Paul Krill. “Ruby on Rails 2.0 released for Web Apps,” InfoWorld. Dec 7, 2007, accessed June 28, 2020, <https://www.infoworld.com/article/2648925/ruby-on-rails-2-0-released-for-web-apps.html> [↩︎][22]
|
|
||||||
|
|
||||||
8. Fielding, 109. [↩︎][23]
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
--------------------------------------------------------------------------------
|
|
||||||
|
|
||||||
via: https://twobithistory.org/2020/06/28/rest.html
|
|
||||||
|
|
||||||
作者：[Two-Bit History][a]
|
|
||||||
选题：[lujun9972][b]
|
|
||||||
译者：[译者ID](https://github.com/译者ID)
|
|
||||||
校对：[校对者ID](https://github.com/校对者ID)
|
|
||||||
|
|
||||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
|
||||||
|
|
||||||
[a]: https://twobithistory.org
|
|
||||||
[b]: https://github.com/lujun9972
|
|
||||||
[1]: https://news.ycombinator.com/item?id=7201871
|
|
||||||
[2]: https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation_2up.pdf
|
|
||||||
[3]: tmp.Ewi4FpMIg6#fn:1
|
|
||||||
[4]: tmp.Ewi4FpMIg6#fn:2
|
|
||||||
[5]: tmp.Ewi4FpMIg6#fn:3
|
|
||||||
[6]: tmp.Ewi4FpMIg6#fn:4
|
|
||||||
[7]: tmp.Ewi4FpMIg6#fn:5
|
|
||||||
[8]: tmp.Ewi4FpMIg6#fn:6
|
|
||||||
[9]: https://www.youtube.com/watch?v=vNoPJqm3DAY
|
|
||||||
[10]: tmp.Ewi4FpMIg6#fn:7
|
|
||||||
[11]: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
|
|
||||||
[12]: tmp.Ewi4FpMIg6#fn:8
|
|
||||||
[13]: https://twitter.com/TwoBitHistory
|
|
||||||
[14]: https://twobithistory.org/feed.xml
|
|
||||||
[15]: https://twitter.com/TwoBitHistory/status/1247187881946275841?ref_src=twsrc%5Etfw
|
|
||||||
[16]: tmp.Ewi4FpMIg6#fnref:1
|
|
||||||
[17]: tmp.Ewi4FpMIg6#fnref:2
|
|
||||||
[18]: tmp.Ewi4FpMIg6#fnref:3
|
|
||||||
[19]: tmp.Ewi4FpMIg6#fnref:4
|
|
||||||
[20]: tmp.Ewi4FpMIg6#fnref:5
|
|
||||||
[21]: tmp.Ewi4FpMIg6#fnref:6
|
|
||||||
[22]: tmp.Ewi4FpMIg6#fnref:7
|
|
||||||
[23]: tmp.Ewi4FpMIg6#fnref:8
|
|
||||||
@ -0,0 +1,120 @@
|
|||||||
|
[#]: collector: (lujun9972)
|
||||||
|
[#]: translator: (CanYellow)
|
||||||
|
[#]: reviewer: ( )
|
||||||
|
[#]: publisher: ( )
|
||||||
|
[#]: url: ( )
|
||||||
|
[#]: subject: (Roy Fielding's Misappropriated REST Dissertation)
|
||||||
|
[#]: via: (https://twobithistory.org/2020/06/28/rest.html)
|
||||||
|
[#]: author: (Two-Bit History https://twobithistory.org)
|
||||||
|
|
||||||
|
被误用的罗伊·菲尔丁的有关描述性状态迁移的博士论文
|
||||||
|
======
|
||||||
|
|
||||||
|
符合描述性状态迁移的 (RESTful,REST译自审定公布名词数据库) 应用程序接口 (API) 无处不在。有趣的是又有多少人真正了解“符合描述性状态迁移”的应有之义呢？
|
||||||
|
|
||||||
|
大概我们中的大多数人都会跟[黑客新闻网站上的这篇公开问答][1]产生共鸣：
|
||||||
|
|
||||||
|
> 我阅读了几篇介绍描述性状态迁移(REST)的文章，甚至包括原始论文的部分章节。然而我仍然对REST
|
||||||
|
到底是什么只有一个相当模糊的想法。我开始认为没有人真的了解它，它仅仅是一个定义相当不充分的概念。
|
||||||
|
|
||||||
|
我曾经计划写一篇有关REST的博客，在里面探讨REST是如何成为这样一个在网络通信领域占主导地位的范式的。我通过阅读[2000年发表的罗伊·菲尔丁(Roy Fielding)的博士论文][2]开始我的研究，这篇博士论文向世人介绍了REST的概念。在读过菲尔丁的博士论文以后，我意识到，相比之下，更引人注意的是菲尔丁的理论缘何受到如此普遍的误解。
|
||||||
|
|
||||||
|
(相对公平地说)很多人知道REST源自Fielding的博士论文，但并没有读过该论文。因此对于这篇博士论文的原始内容的误解才得以流行。
|
||||||
|
|
||||||
|
最大的误解是：这篇博士论文直接讨论了构建API(API)的问题，我此前一直认为REST从一开始就打算成为构建在超文本传输协议(HTTP)之上的网络API(Web API)的架构模型，我相信很多人也这样认为。我猜测此前可能存在一个混乱的试验时期，开发人员采用完全错误的方式在HTTP基础上开发API，然后Fielding出现了并提出了将REST做为网络应用程序开发的正确方式。但是这种想法的时间线对不上：我们今天所熟知的网络服务的API并非是在Fielding出版他的博士论文之后才出现的新生事物。
|
||||||
|
|
||||||
|
Fielding的博士论文(名为“架构风格与基于网络的软件架构设计”)(译者注，网络中文版的中文译名)不是讨论如何在HTTP的基础上构建API，而恰恰是讨论HTTP本身。Fielding是HTTP/1.0版规范的贡献者同时也是HTTP/1.1版的共同作者。有感于从HTTP的设计中获得的架构经验，他的博士论文将REST视为指导HTTP/1.1的标准化过程的架构原则的精华。举例而言，他拒绝了使用`MGET`和`MHEAD`方法进行批量请求的提议，因为他认为这违反了REST所定义的约束条件，尤其是在一个符合REST的系统中传递的消息应该是易于代理和缓存的约束条件。[1][3]因此，HTTP/1.1转而围绕持久性连接设计，在此基础上可以发送多个HTTP请求。（Fielding同时认为网页保存在本地的浏览记录(cookies)是不RESTful的，因为它们在一个状态无关的系统中增加了状态描述，然而它们的应用已经根深蒂固了。)[2][4]Fielding认为，REST并非构建基于HTTP的系统的操作指南，而是扩展HTTP的操作指南。
|
||||||
|
|
||||||
|
这并不意味着Fielding认为REST不能用于构建其他系统。只是他假定其他系统也是“分布式超媒体系统”(distributed hypermedia systems)。人们对REST还有另一个误解：认为它是一个可以用在任何网络应用中的通用架构。但是从这篇博士论文中Fielding介绍REST的部分你基本上能够得出如下的结论，“请注意，我们只设计了HTTP，但是如果你发现你自己也在设计一个_分布式超媒体系统_，你也应该采用我们提出的称为REST的优秀架构，以让开发变得更容易”。有鉴于互联网已经存在了，我们尚不清楚为什么Fielding认为有人可能试图重新创建这样一个(和HTTP一样的)系统。或许在2000年的时候世界上仍然存在应用不只一个分布式超文本系统的空间吧。无论如何，Fielding已经说得很清楚了，REST意在提供一套解决方案，来解决在试图经由网络连接超文本内容时出现的弹性伸缩与一致性问题，_而不是_作为分布式应用的通用架构模型。
|
||||||
|
|
||||||
|
我们现在只记得Fielding的博士论文提出了REST的概念，但事实上，他的博士论文是在讨论通用的软件架构有多么糟糕以及如何更好地选择符合你需求的软件架构。这篇博士论文中仅用了一个章节来讨论REST本身，大量的文本内容都都花在了对你能够在网络应用中运用的不同的架构风格[3][5]的分类上。这些架构风格包括：受Unix的管道设计启发的管道-过滤器(Pipe-and-Filter, PF)风格，客户-服务器(Client-Server, CS)风格的多种改型。这些改型包括分层-客户-服务器(Layered-Client-Server, LCS)风格、客户-缓存-无状态-服务器(Client-Cache-Stateless-Server,C$SS)风格和分层-客户-缓存-无状态-服务器(Layered-Client-Cache-Stateless-Server, LC$SS)。这些原始风格未必实用，但是Fielding认为我们可以通过混合匹配现有风格提供的约束条件来派生出新的风格。REST就是通过这种方式产生的，因此也可以称之为一致性-分层-按需代码-客户-缓存-无状态-服务器(Uniform-Layered-Code-on-Demand-Client-Cache-Stateless-Server, ULCODC$SS)风格，虽然我们并没有这样做。Fielding建立上述分类是为了强调(每一种风格对应的)约束适用于不同的应用。而上述最后一种风格对应的约束是他所认为的最适用于HTTP的。
|
||||||
|
|
||||||
|
今天，REST的无处不在是极具讽刺意味的。REST在各种各样的网络应用中被盲目使用，但是Fielding最初只是将REST视作一种指引，通过它指导人们裁剪一种软件架构来适应独立应用的特殊需求。
|
||||||
|
|
||||||
|
我极力弄清楚这是如何发生的，毕竟Fielding已经明确地指出了不让形式服从功能的陷阱。他在论文的一开始就作出了警告：由于没有正确地理解软件架构而“使用流行的架构设计是经常发生的”[4][6]。他在几页之后又重新强调了这一点：
|
||||||
|
|
||||||
|
> 一些架构风格经常被认为是适用于一切软件形式的锦囊妙计。然而，一名资深的设计人员应该选择能够满足解决特定问题的需要的架构风格[5][7]。
|
||||||
|
|
||||||
|
REST自身显然不是这样的锦囊妙计。正如Fielding所指出的，它包含了可能不合适的利弊权衡，除非你试图构建一个分布式超媒体应用：
|
||||||
|
|
||||||
|
> REST设计用来进行大粒度的超媒体数据传输，并对网络应用场景中的常用见情形做了优化，但是可能会导致其在与其他形式的软件架构相互作用时不协调。[6][8]
|
||||||
|
|
||||||
|
Fielding提出REST是因为网络发展提出了“超越政府的可扩展性(anarchic scalability)”这一棘手问题。在Fielding看来“超越政府的可扩展性”意即跨越不同组织与政府的边界进行文档的高效连接的需求。REST所应用的约束是仔细选择的以用来解决这一“超越政府的扩展性”问题。_面向公众_的网络服务API同样需要解决类似的问题，因此可以理解为什么REST在这些应用中是适用的。时至今日，即使后端应用只需要同工程团队具有完全控制权的客户端交互，仍然有工程团队使用REST开发后端应用，这样的发现一点也不令人惊讶。我们都成为了[蒙蒂巨蟒团队(Monty Python)的独幕滑稽剧][9]中的建筑师，那位建筑师设计了一座具有屠宰场风格的公寓大楼，因为他们只有修建屠宰场的经验。(Fielding使用了这部滑稽剧中的一句台词作为他的博士论文的题词：打扰一下，你说的是“刀”吗？)
|
||||||
|
|
||||||
|
有鉴于Fielding的博士论文一直在极力避免提供一种放之四海而皆准的软件架构，REST又怎么会成为所有网络服务的事实上的标准呢？
|
||||||
|
|
||||||
|
我认为，在21世纪头十年的中期人们已经厌倦了简单对象访问协议(SOAP)，因此想要创造另一种属于他们自己的四字首字母缩略词。
|
||||||
|
|
||||||
|
|
||||||
|
我只是半开玩笑。简单对象访问协议(SOAP)是一个冗长而复杂的协议，以致于你没法在不事先理解一堆互相关联的可扩展标记语言(XML)规范的基础上使用它。早期的网络服务提供基于SOAP的API。在21世纪头十年中期，随着越来越多的API的提供，被SOAP的复杂性激怒的软件开发者随之集体迁移。
|
||||||
|
|
||||||
|
SOAP引起了这群人的蔑视，Rails 之父戴维·海涅迈尔·汉森( David Heinemeier Hansson，译自其所著的《重来》的中文版的作者译名)曾经评论：“我们感觉SOAP过于复杂了，它已经被企业人员接管。而当这一切发生的时候，通常没有什么好结果。”[7][10] 始于这一标志性的评论，Ruby-on-Rails于2007年放弃了对SOAP的支持。“企业人员”总是希望所有内容都被正式指定，反对者认为这是浪费时间。
|
||||||
|
|
||||||
|
如果反对者不再继续使用SOAP，他们仍然需要一些标准化的方式来进行工作。所有人都在使用HTTP，而且因为HTTP对代理与缓存的支持，所有人都至少会继续使用HTTP作为传输层。因此最简单的解决方案就是依赖HTTP的现有语义。这正是他们所做的工作。他们曾经称之为：去它的，重载HTTP(即FIOH)。这曾经是真实的名称，任何曾经试图决定业务逻辑错误需要返回什么HTTP状态码的人都能证明这一点。但是在所有进入SOAP的正式规范工作的映衬下，这显得鲁莽而乏味。
|
||||||
|
|
||||||
|
幸运的是，出现了这篇由HTTP/1.1规范的共同作者创作的博士论文。这篇博士论文与扩展HTTP有某种模糊的联系，并给予了FIOH一个具有学术体面的外表。因此REST非常适合用来掩饰其实仅仅是FIOH的东西。
|
||||||
|
|
||||||
|
我并不是说这是真正发生的事情，或者在所有对REST的滥用初期存在一个真实的阴谋，但是这段历史有助于我理解这样一个现实，即在Fielding的博士论文根本就不是讨论网络服务API的情况下，REST是如何成为用于网络服务API的架构模型的。采用REST的约束存在一些效果，尤其是对于那些面向公众的需要跨越组织边界的API来说。这些API通常会从REST的“统一接口”中受益。这应该是REST起初被提及与构建网络API相关的核心原因。但是想象一个部分因为市场的原因借用了“REST”这一名称的独立存在的被称为“FIOH”的架构，这有助于我理解存在于我们今天所理解的RESTful API与Fielding最初描述的REST的架构风格之间的诸多差异。
|
||||||
|
|
||||||
|
举例而言，追求纯正的REST的人经常抱怨，那些所谓RESTful API实际并不是REST API，因为它们根本就没有使用超文本作为应用程序状态引擎(HATEOAS)。Fielding本人也做出过[这样的批评][11]。根据Fielding的观点，一个真正的REST API应当允许你通过跟随链接实现从一个基础端点访问所有的端点。如果你认为这些人的确在试图构建RESTful API，那么存在一个明显的疏漏——使用超文本作为应用程序状态引擎的确是Fielding最初提出的REST概念的基础，尤其是考虑到“描述性状态迁移(REST)”中的“状态迁移(ST)”意指使用资源之间的超链接进行状态机的导航(而不是像很多人所相信的那样通过线路传输资源状态)[8][12]。但是你试想一下，如果每个人都只是在构建FIOH的API，并明里暗里的将之作为REST API宣传，或者更诚实一点说是作为RESTful API宣传，那么自然使用超文本作为应用程序状态引擎也就不重要了。
|
||||||
|
|
||||||
|
类似的，你可能会感到惊讶：尽管软件开发者喜欢不断地争论使用PUT方法还是使用PATCH方法来更新资源更加RESTful，Fielding的博士论文却没有讨论HTTP中的方法与增删改查(CURD)操作之间的映射关系。在HTTP操作与CURD操作之间建立一个标准的映射表是有用的，但是这一映射表是FIOH的一部分而不是REST的一部分。
|
||||||
|
|
||||||
|
这就是为什么我们应该认为“REST”这一术语是被误用了而不是说没有人理解REST。REST API这一现代概念与Fielding的REST架构之间存在历史联系，但事实上它们是两个不同的概念。历史联系适合作为确定何时构建RESTful API的指引而留在心底。你的API需要像HTTP那样跨越组织和政府边界吗？如果是的话，那么构建具有统一的可预测的接口的RESTful API可能是正确的方式。如果不是的话，你最好记住，Fielding更倾向于形式服从功能。或许类似 GraphQL 的方案或者仅仅 JSON-RPC 更适合您试图完成的工作。
|
||||||
|
|
||||||
|
|
||||||
|
1. Roy Fielding. “Architectural Styles and the Design of Network-based Software Architectures,” 128. 2000. University of California, Irvine, PhD Dissertation, accessed June 28, 2020, <https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation_2up.pdf>. [↩︎][16]
|
||||||
|
|
||||||
|
2. Fielding, 130. [↩︎][17]
|
||||||
|
|
||||||
|
3. Fielding distinguishes between software architectures and software architecture “styles.” REST is an architectural style that has an instantiation in the architecture of HTTP. [↩︎][18]
|
||||||
|
|
||||||
|
4. Fielding, 2. [↩︎][19]
|
||||||
|
|
||||||
|
5. Fielding, 15. [↩︎][20]
|
||||||
|
|
||||||
|
6. Fielding, 82. [↩︎][21]
|
||||||
|
|
||||||
|
7. Paul Krill. “Ruby on Rails 2.0 released for Web Apps,” InfoWorld. Dec 7, 2007, accessed June 28, 2020, <https://www.infoworld.com/article/2648925/ruby-on-rails-2-0-released-for-web-apps.html> [↩︎][22]
|
||||||
|
|
||||||
|
8. Fielding, 109. [↩︎][23]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
via: https://twobithistory.org/2020/06/28/rest.html
|
||||||
|
|
||||||
|
作者：[Two-Bit History][a]
|
||||||
|
选题：[lujun9972][b]
|
||||||
|
译者：[CanYellow](https://github.com/CanYellow)
|
||||||
|
校对：[校对者ID](https://github.com/校对者ID)
|
||||||
|
|
||||||
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||||
|
|
||||||
|
[a]: https://twobithistory.org
|
||||||
|
[b]: https://github.com/lujun9972
|
||||||
|
[1]: https://news.ycombinator.com/item?id=7201871
|
||||||
|
[2]: https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation_2up.pdf
|
||||||
|
[3]: tmp.Ewi4FpMIg6#fn:1
|
||||||
|
[4]: tmp.Ewi4FpMIg6#fn:2
|
||||||
|
[5]: tmp.Ewi4FpMIg6#fn:3
|
||||||
|
[6]: tmp.Ewi4FpMIg6#fn:4
|
||||||
|
[7]: tmp.Ewi4FpMIg6#fn:5
|
||||||
|
[8]: tmp.Ewi4FpMIg6#fn:6
|
||||||
|
[9]: https://www.youtube.com/watch?v=vNoPJqm3DAY
|
||||||
|
[10]: tmp.Ewi4FpMIg6#fn:7
|
||||||
|
[11]: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
|
||||||
|
[12]: tmp.Ewi4FpMIg6#fn:8
|
||||||
|
[13]: https://twitter.com/TwoBitHistory
|
||||||
|
[14]: https://twobithistory.org/feed.xml
|
||||||
|
[15]: https://twitter.com/TwoBitHistory/status/1247187881946275841?ref_src=twsrc%5Etfw
|
||||||
|
[16]: tmp.Ewi4FpMIg6#fnref:1
|
||||||
|
[17]: tmp.Ewi4FpMIg6#fnref:2
|
||||||
|
[18]: tmp.Ewi4FpMIg6#fnref:3
|
||||||
|
[19]: tmp.Ewi4FpMIg6#fnref:4
|
||||||
|
[20]: tmp.Ewi4FpMIg6#fnref:5
|
||||||
|
[21]: tmp.Ewi4FpMIg6#fnref:6
|
||||||
|
[22]: tmp.Ewi4FpMIg6#fnref:7
|
||||||
|
[23]: tmp.Ewi4FpMIg6#fnref:8
|
||||||
Loading…
Reference in New Issue
Block a user