17 ms·

Roy Fielding's Misappropriated REST Dissertation (2020)

197 points by fagnerbrack 5y ago

account-5 5y ago
This article is timely, thanks. I'm learning this stuff at the minute. And based on the description provided of REST I couldn't marry it up what what the course was later describing as REST. This article has made sense of that for me.
DeathArrow 5y ago
>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 That's somewhat ironic given that anybody is using "RESTful" APIs now.
DeathArrow 5y ago
Long story short: -if you are designing a public API it might pay to make it "RESTful" and even use HATEOAS -if your API isn't public, the it might be better to find a schema that better fits your particular problem -if your clients aren't browsers - there's nothing to gain by using RSET, HTTP and JSON, apart from familiarity.
Semaphor 5y ago
Last year, 179 comments: https://news.ycombinator.com/item?id=23670238 https://news.ycombinator.com/item?id=23670238
beachy 5y ago
HATEOAS has never really grabbed me. Not least because, despite HN now swung hard against microservices, they exist often for a reason, and it's difficult for one service to emit hypermedia for another. The inspiration was humans surfing freely through interlinked web pages, but API clients just don't naturally do that.
- bryanrasmussen 5y ago
  I always understood application in HATEOAS to be referring to the browser or whatever type of application sitting on some machine somewhere had been written to consume hypertext, but it sounds like you're considering a service to be the application?
  - beachy 5y ago
    I was referring to something like this. Here's a hypermedia API entry point I googled up. GET / { "version": "1.2.3", "description": "Example API to manage orders", "links": [ { "rel": "orders", "href": "/orders" }, { "rel": "customers", "href": "/customers"}, { "rel": "customer-by-id", "href": "/customer/{id}"}, { "rel": "customer-by-email", "href": "/customer{?email}"}, ... ] } My point was, how is such an API served up when it spans resources that are managed by two separate services / microservices - one for customers, one for orders? Of course this is a simple example, we are smart tech heads, so obviously we can wedge a third service in front of the other two, which exists solely to provide aggregating behavior like this. But why? Is hypermedia so useful that it's worth going to this trouble? (No IMHO).
    - eyelidlessness 5y ago
      Django REST Framework (and I’m assuming later work by its authors) get this right and literally populate URLs rather than giving you patterns.
      - beachy 5y ago
        Not familiar with Django sadly but it sounds like it would act as something of a proxy that sits in front of your microservices. My point is that if you are starting with just e.g 2 microservices, one for customers, one for orders, then hypermedia on it's own is not useful enough to justify adding a new proxy/ layer, just so that an API produced by one of those microservices can include hypermedia for the other.
quantified 5y ago
FIOH is a great addition to the lexicon.
- Toutouxc 5y ago
  I wouldn't mind using "FIOH API" instead of "well the API is RESTful, I mean, it isn't really RESTful, but we use HTTP methods on resource-based endpoints and a couple of HTTP status codes to represent our mostly CRUD-ish actions".
deleted 5y ago
[deleted]
ramesh31 5y ago
REST is far too narrow to fully encapsulate the features necessary in even the most basic of web apps. A truly RESTful API is essentially just a database. So application backends always ends up being a JSON RPC API over HTTP. Better to formalize that with an RPC framework than zealously attempt sticking to something that is inadequate.
- eyelidlessness 5y ago
  I’m disappointed to see this comment. What don’t you think can be expressed with REST that can be with RPC?
  - lmm 5y ago
    Custom verbs. REST is a recapitulation of "Execution in the Kingdom of Nouns" as a network metaprotocol rather than a programming language.
    - rswail 5y ago
      YAGNI most of the time. Custom verbs change the focus to the verb. The verb is not visible because it's ephemeral during the "call". Whereas the state of the Noun is clear. Verbs are also not idempotent for the most part, whereas it's relatively easy to ensure that the non-idempotent HTTP verbs (POST, PUT/PATCH, ignoring DELETE) can be made "repeatable" with use of etags or other unique identification.
      - lmm 5y ago
        > Custom verbs change the focus to the verb. Which is often what you want - a lot of things in the real world are more easily understood through verbs than nouns, which is what the essay is all about. REST says that everything has to be an entity, which is why so many "REST" APIs end up just exposing their database as CRUD rather than offering a vocabulary that actually makes sense for the domain. When nouns are the only important things in your domain then it works. When verbs are important in your domain it doesn't. > it's relatively easy to ensure that the non-idempotent HTTP verbs (POST, PUT/PATCH, ignoring DELETE) can be made "repeatable" with use of etags or other unique identification. Most "REST" APIs "in the wild" don't actually do that (or, worse, do it incorrectly), so I'd question the idea that it's actually easy in practice.
eyelidlessness 5y ago
Ugh. REST and HATEOAS are just, only just: 1. an affirmative statement that HTTP semantics are mature and robust enough to express networked application communication 2. that using those semantics is better than not, when communicating over HTTP This shouldn’t be controversial! Want GraphQL? Cool, ?foo[bar]=quux. Want a special data transport format? Cool, Content-Type: application/furby. Want a big blob of different content? Multipart has your back. There’s nothing special about REST. Use the format! The only special thing is you have to… use it. POST / everything ain’t that. Sure it’s convenient for your custom format that doesn’t interop with anything. And then it’s a decade of articles about no one using common standards. Welp, this standard was here all along.
- lmm 5y ago
  > Ugh. REST and HATEOAS are just, only just: > 1. an affirmative statement that HTTP semantics are mature and robust enough to express networked application communication > 2. that using those semantics is better than not, when communicating over HTTP No they're not. Read the dissertation. HATEOAS is a specific thing and using HTTP semantics doesn't mean you're doing HATEOAS. The article is completely right; what you're advocating for is FIOH.
- pornel 5y ago
  Clarifications from Roy himself: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... • A REST API should not be dependent on any single communication protocol • A REST API must not define fixed resource names or hierarchies • A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) • A REST API should spend almost all of its descriptive effort in defining the media type This is the exact opposite of what people usually do and call it "REST": a predefined URL scheme for JSON tied to HTTP semantics (this not to say that Roy's REST is in any way better; JSON over HTTP is nice. It's just funny that popular definitions of REST have flipped 180°).
  - regularfry 5y ago
    Also a useful reference: https://martinfowler.com/articles/richardsonMaturityModel.html https://martinfowler.com/articles/richardsonMaturityModel.ht...
RandyRanderson 5y ago
SOAP, REST, Big Data, microservices - it's funny how, at the time, everyone seems to be unbelievably vociferous that <technology_of_the_moment> is the only way to do things and that we should all be thankful that the great magnet in the sky gave us this sacred cow. Then, 5 years later, it's obviously the worst thing ever next to the <new_hotness>. <new_hotness> always being unevenly in some ways worse and in others better. We need to, in our exuberance, ask ourselves: what are the current false Gods? Are we technologists that reason or a headless flock?
- brylie 5y ago
  AWS Lambda?
- rswail 5y ago
  REST was never about "technology", it's about an architectural style that is particularly suited to a networked separation of API consumers and producers. SOAP was an overengineered set of "standards" that had enough wiggle room that none of the SOAP implementation would interoperate correctly. "microservices" are just "services". The technology that allows them, also allows for horizontal scaling, especially if you ensure that your API is stateless (not the resources, by definition, they have state, that's what you're "transferring"). I've been doing this stuff for 30 years now, and the more things change, the more they stay the same. IMNSHO, the current false Gods are all the "cloud" items. The infrastructure stuff in AWS/GCP/Azure is just... networking and servers with APIs on top. There's nothing particularly special, except that the APIs let you avoid thinking about the underlying infrastructure. As the cloud climbs the software stack, from IaaS, to PaaS (eg RDS), to SaaS (eg Stripe), it's interesting that the APIs remain primarily HTTP/JSON (or XML) and "RESTful" for the most part.
- DeathArrow 5y ago
  People would use what is trendy because they think doing so it's safer, brings them more jobs and has support.
deleted 5y ago
[deleted]
rswail 5y ago
Yes, Fielding's dissertation backronymed the HTTP protocol into REST, but the concept of resource driven design also exists. The benefits of applying the REST style is: 1. Limiting the verbs makes you focus on the nouns (URIs) and the description of them. 2. REST verbs do NOT "map" to CRUD in a database. This is overloading the REST style to match a server's implementation. What or how a server (or client) maintain the state of a resource is up to that server/client. 3. HATEOAS is not really achievable for naive clients. Browsers "expose" the links to the human user to enable the user to navigate. HTML provides the particular media type to expose that navigation. 4. If a server and clients agree on a media type, then as part of that agreement is the interpretation of attributes, like "link" elements with "rel" and "href" attributes. 5. RPC (whether as ONC-RPC, CORBA, XML-RPC, JSON-RPC) etc is brittle. It usually requires both the client and server to upgrade their understanding of the interface simultaneously and makes it hard to version or separate the system elements. This lesson has to be learned over and over as programmers realize that "remote" procedure calls are not local and can't use the same semantics. 6. The process I've followed (successfully) is: * Define a "well known" URL. I use "/versions" that returns a media type that describes the available API versions, attributes of them like "not before" and "not after" and a versioned endpoint for subsequent usage. This allows clients and servers to evolve independently. The versions follow semver, so it's clear when there's breaking and non-breaking changes. * Define resources in terms of their state (via a FSM) and transitions. Map the transitions to HTTP verbs, along with media types that describe the change in state. * The transitions should be expressed in terms of the resource, not CRUD. Don't talk about "Create Account", you "open" an account. In business terms, it is very rare that you "delete" something. In addition, HTTP semantics means that you can't return a message body for the DELETE verb. * Using PUT vs PATCH can be avoided by exposing the things that you want to "PATCH" via sub-resources in the URL pattern (or appropriate HREFs in the parent resource). Including the sub-resource attributes in the parent (when you GET it for example) should be selectable via a query parameter on the GET. However, where possible, use GETs of the sub-resources and cache them appropriately. The net result is that you have an API that is consumable mostly automatically, with the agreed media types defining the necessary navigation. I've never used downloadable code as it hasn't been necessary, but it's relatively easy to see how to extend the media types to include links to the code (ie the equivalent of <script> tags). Unfortunately protobufs have re-introduced the concept of RPC style APIs and they absolutely suck, even if protobuf does allow you to version the messages. You still need to exchange the proto headers and recompile code to update. It's still brittle RPC underneath, because programmers can't be assed dealing with network failures or other issues or with proper internal versioning of the underlying implementations. There's really no need for most use-cases to use anything other than HTTP, the standard verbs and their interpretation, URLs (potentially with patterns but avoidable with proper links), and JSON media types/schemas. Compression of the JSON makes it mostly equivalent to protobuf on the wire, HTTP/2 etc avoids the single threaded nature of the HTTP TCP connection.
rswail 5y ago
Back in the day, I was on a yahoo group that had the REST evangelists pushing for how REST maps much better to consumable APIs than the enterprise nonsense that SOAP/WSDL/WS-* and all that created. The SOAP people disagreed because they wanted everything defined up front between parties, out of band and then the enterprise companies started selling "tooling" to over-engineer and "manage" this nonsense. Soon there was "governance" introduced so that centralized control of APIs could be configured and managed. Of course, the different implementations couldn't interoperate, so there was classic "supplier lockin" to your chosen Enterprise-Ready WS-* infrastructure (tm). WS-Addressing introduced resource addressing over XML over HTTP that overloaded the equivalent of a URL. Just one example. REST in general (HTML/JS/HTTP in particular) has proven to be scalable, understandable, and implementable, without all the associated nonsense that WS-* dragged in. Want encryption in transit? TLS provides that. Want caching of results on either client or server or intermediate? HTTP Etags and headers provide that. About the only thing that REST over HTTP doesn't provide is sessions, but JWTs and OAuth now handle most of that.
- andrewf 5y ago
  My favorite WS-* is WS-I, a bunch of guidelines about which versions/subsets of the other standards to use, if you actually want to talk to someone else. (As someone who once had to implement a SOAP server supporting diverse clients, I'll never pass up a chance to get a dig in)
  - function_seven 5y ago
    I remember the time someone told me what the "S" in SOAP stood for. They were clearly pranking me; I refused to believe it. And to this day, nobody will give me the real answer! Whole world is in on this prank, and I've given up trying to find out.
    - wsc981 5y ago
      Obligatory reference “S Stands For Simple: http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple
posharma 5y ago
With the popularity of grpc and thrift I've not seen many cases where REST is needed for internal communication. I understand it's required for external communication though. Grpc and thrift are kind of the opposite direction APIs are taking (or have already taken) as in don't we hate RPCs? We do but speed and efficiency are much more important for internal comm (and binary protocols are just one of the factors at play here).
- jseban 5y ago
  Yeah, it's designed for discoverable APIs on the open internet, why use it for internal communication I have no idea. All the time I've wasted making apps slower and worse, and arguing over it, just because it's the "correct" RESTful way, and creating and maintaining documentation, when there's only one single client, and it's also managed in the same team. It just becomes a line drawn in the code in a random place where everything becomes more difficult, dogmatic and impractical.
  - DeathArrow 5y ago
    >why use it for internal communication I have no idea Here are a few potential reasons: 1. HTTP is familiar 2. RESTful seems easy 3. people are told that RESTful is the way to go, is cool is mainstream and is modern
shadeslayer_ 5y ago
"..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." This bit is particularly important to me personally because I have been that guy in the past. As a new grad fresh out of college, someone taught me REST and I was.. impressed. I thought it was the only way to design web backends. It was my hammer and everything else I saw was a nail. A few years on, I can look back and understand how stupid I was.
M0r13n 5y ago
Building a proper rest API is pretty hard. I think I speak for many developers when I say that I limit myself to the most important core statements. For most applications, a simple API + HTTP + sensible url scheme is completely sufficient. Especially when the API doesn't need to be publicly consumable. The author himself says that as a good designer you should select a style that matches the needs of a particular problem being solved. Things like URL Autodiscovery are definitely desirable from an idealistic or academic point of view. However, I have never seriously needed such features.
- jseban 5y ago
  > Things like URL Autodiscovery are definitely desirable from an idealistic or academic point of view. However, I have never seriously needed such features. Yeah I'm so tired of this bs from developers who treat their jobs as an idealistic academic exercise instead of doing what makes sense for the organisation. They don't work for Roy Fielding for christ's sake, so why are they spending so much time and effort supporting his research?
hyperpallium2 5y ago
The only benefit of REST is caching.
streamofdigits 5y ago
I wonder if the reason HATEOAS is not taken more seriously / developed further is simply the economic / cultural context of the dominant style of software development during the past decade (centralization, winner-takes-all, command-and-control etc) rather than something intrinsic about the architecture A decentralized web (as originally imagined) involves countless diverse servers and clients exchanging data of constantly evolving (as in: growing in complexity) semantic structures. What is needed is not inventing a "language to rule all languages" but inventing the dictionary. If there is an alternative pattern that can somehow enable a truly functional decentralized web please step forward.
- regularfry 5y ago
  XHTML. Seriously. If what you want looks like an extensible document type with custom embedded data that you want to reliably parse out, that's what it's there for.
  - streamofdigits 5y ago
    the "X"(ML/HMTL/...) universe seems to have been deprecated but lots of boring people out there that need to manage real life complexity seem to wonder the wisdom of the "in crowd" progress has sometimes a strange "helix" like structure: revisiting and re-using valuable old patterns after fixing their pain points
- DeathArrow 5y ago
  I don't know about the others but I don't use HATEOAS because 1. is simpler not to and 2. I don't have a need for it
- jrochkind1 5y ago
  I think you're right, but I also think the cause-and-effect is pretty bilateral. Designing implementing and maintaining that kind of decentralized HATEOS/"semantic web" (there's a simlarity, right?) infrastructure, in a way that actually works well... is very expensive. More expensive than it's (non-"political"[1]) benefits. People do things where the immediate benefit is worth the immediate cost. That is, there is something intrinsic about the architecture that is both suitable to decentralization, and more complicated/expensive for not enough obvious benefit to those who pay the expense. And these are related. [1] "political" in the sense of "where the power lies". And they are real benefits there to decentralized infrastructure (at least for those who aren't going to be in the center). But the way our economy and society works, they don't produce funding to create.
austincheney 5y ago
There were two key discoveries that Fielding proposed regarding URI, one of which is REST. The other is that URI may serve as a universal unique identifier that works regardless of whether a resource is resolved to a given address.
throw_m239339 5y ago
I just moved everything to basic JSON RPC with GET and POST when I'm not using GraphQL. Etags are useful for caching and that's basically it. Fielding dissertation is a fantastic academic exercise, but I don't have time to debate the "true meaning of REST" with my coworker, like I did for 15 years. remote API are no different from libraries, you can use semvers to version them it's up to the client to detect whether the API breaks at some point or not. As for the idea of resource based design, HATEOAS and "smart clients", it's as dead as the semantic web.
- lloydatkinson 5y ago
  Yes this is my thoughts too. Though I include a DELETE in that small list. Seriously, it's been years and years and people still don't know what REST actually is. Neither do I, because everyone else gives a different explanation. It's a mess.
- acdha 5y ago
  > Fielding dissertation is a fantastic academic exercise, but I don't have time to debate the "true meaning of REST" with my coworker, like I did for 15 years. I think this is a very true point: GraphQL certainly has analogous challenges but doesn’t seem to have developed the quasi-academic cult debating how many angels can dance on the head of a pin[1]. I remember so many pointless arguments that something had to be built in a theologically-correct manner even if it wasn’t a natural fit for the problem and there was no known user who wanted that behavior. 1. As with other things like Agile, this isn’t a criticism of Fielding but rather what came after that success, especially the people who wanted to talk like academics without attempting the rigor.
  - naasking 5y ago
    > I remember so many pointless arguments that something had to be built in a theologically-correct manner even if it wasn’t a natural fit for the problem I don't think most of the arguments were about building something RPC-like, the people complaining were just saying "stop calling RPC APIs REST", and that's perfectly reasonable. REST is totally not just RPC over HTTP.
jensneuse 5y ago
My personal take, don't decide between REST, SOAP, GraphQL, etc.. to build APIs but rather combine the best of all of them. I wrote about this topic a while back: https://wundergraph.com/blog/the_fusion_of_graphql_rest_json_schema_and_http2 https://wundergraph.com/blog/the_fusion_of_graphql_rest_json...
virtualritz 5y ago
> This is the deep, deep irony of REST’s ubiquity today. REST gets blindly used for all sorts of networked applications now [...] This. I don't even know where to start if I were to talk about the idiocy behind stateless networked apps on my phone. My fav. example are car/scooter sharing apps. Some even 'forget' the map tiles between screen locks. But pretty much all of them 'forget' your active booking. And the route to the vehicle. Which is just great when you are walking from a party (where you had the host's WiFi to do the booking) in a neighborhood with shitty mobile network, in Winter. For something like ShareNow it can take up to three minutes on an 'E' connection to load missing map data, active booking and route to car. If your phone locks screen during that time ... just unlock and ... wait another three minutes. You may have guessed that I'm talking first hand experience here. Frequently so, ofc. I'm using these apps heavily here in Berlin, since 2014. It's the reason I bought gloves that let you use a touchscreen. Not kidding. Even though it's valid for 20 minutes and the likeliness of the the vehicle becoming unavailable due to reasons outside of the user canceling the booking or changing the phone's system time are pretty much non-existent even this info is not retained on the Phone. Because that would entail state. The idea that the network interface of an app can be RESTful yet the app itself can carry state and cache stuff on the phone – and that is A-OK – seems absent from the minds of whoever develops this. EDIT: typo(s)
- twic 5y ago
  These apps are poorly written, but this has nothing to do with REST, or HTTP being stateless. Indeed, HTTP being stateless forces apps to implement state management which can naturally survive network interruptions. If the apps you are complaining about used a stateful protocol, they would be even worse!
  - virtualritz 5y ago
    Maybe you misread me. I said the the protocol can be stateless but the app itself, towards the user, should carry state – where this makes sense. E.g. in the cases I described.
- alangibson 5y ago
  I'm not saying REST is the right approach to the apps you describe, but nothing you're describing is a REST issue per se. You're describing incompetent handling of network disconnects, cache invalidation and many more. Theses are issues that plague all distributed systems.
throw0101a 5y ago
> 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 I'd be curious to see a web without cookies. I understand the desire for stateless, but given how many things need logins and an user "session" how would that work without cookies?
- DeathArrow 5y ago
  >I understand the desire for stateless, but given how many things need logins and an user "session" how would that work without cookies? RESTful is ok for public APIs. If you design both the client and server, you don't need to be stateless.
  - jseban 5y ago
    > If you design both the client and server, you don't need to be stateless. And you also don't need to be RESTful.
DeathArrow 5y ago
>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. Are there know architectural models better suited to build microservices? GraphQL, grpc are constructed on top of HTTP which according to the article uses REST as inspiration.
- rswail 5y ago
  grpc is RPC. It's in the name.
  - DeathArrow 5y ago
    Yes, but relies on HTTP.
DeathArrow 5y ago
Working on a big microservice solution right now, it amazes me how inefficient we are: we are making HTTPL calls, replying HTTP calls, serializing data to JSON, deserializing data from JSON in a long chain of calls. I rather see a distributed application the same way as I see a monolithic application: I don't want to make HTTP calls, I don't want to serialize JSON, what I want is to call remote functions with my local data in a reliable, fast and efficient way. It seems weird that we can't just do that and instead we pack the data in layers upon layers, thus decreasing performance and increasing complexity a bit.
- coredog64 5y ago
  Same: At one point, we analyzed our app and determined that about half the assigned compute was being used for serializing and deserializing JSON. If the project wasn’t also years late they would have moved to Protobuf and saved millions.
  - naasking 5y ago
    Or use Cap'n Proto [1] and eliminate all serialization costs. [1] https://capnproto.org/ https://capnproto.org/
mcherm 5y ago
The article writes: > 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 First of all, I fully agree with this article. I lived through this transition and my own reasoning is well as that of basically everyone I talked to was really just that the existing infrastructure was overly complicated, while "just passed some JSON over HTTP" was easy. I do, however, want to disagree with one point quoted above. The proxying and caching support were not the reasons why FIOH was based on HTTP. The reason was firewalls. At first, almost all of the things I built and almost all of the RESTful APIs I saw published, were really just some form of remote procedure call. Caching was supported in theory but hardly ever used in practice. However, it was policy pretty much everywhere to have firewalls that blocked traffic to most ports other than 80 and 443. The more advanced firewalls also verify that traffic over those ports was actually HTTP traffic. So it wasn't possible to build any kind of an API that wasn't based on HTTP -- it would have been impossible to deploy and use without getting permission from the firewall and security teams on both the client and server and of the connection.
- fieldcny 5y ago
  This was my experience as well, trying to convinced enterprise security folks to let new protocols through firewalls was nearly impossible. The difficulty was exponentiated for api/service calls inbound to the organization. SOAP services, even though they went over http, had to go through special inspection devices because XML parsing libraries were so complex and prone to parsing issues and security vulns.
  - voakbasda 5y ago
    > SOAP services, even though they went over http, had to go through special inspection devices because XML parsing libraries were so complex and prone to parsing issues and security vulns. So did the person who ordered that inspection device realize that the SOAP streams under inspection would be examined using a set of XML parsing libraries that are complex and prone to vulnerabilities? Seems like this setup just creates another device that must be maintained. Perhaps the solution would be to use another machine to inspect the inspection devices. Turtles all the way down.
jrochkind1 5y ago
> 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) Having been a developer during that period of history, I'd say OP gets it about right, that's what happened. For better or worse; it's not obvious to me that it was a poor choice. I do agree it somewhat misappropriated the "REST" term and misrepresented itself as being more "standardized" than it was -- also for more or less the reasons OP suggests: "that would have seemed recklessly blasé next to all the formal specification work that went into SOAP… a veneer of academic respectability". Although I do recall some people right from the start really were interested in HATEOAS and trying to do it... I think it's practical benefits were somewhat elusive. It reminds me of "semantic web" in some ways, not sure if that makes sense...
- bsenftner 5y ago
  I remember consulting for a tech company around '07 that needed to send remote (extremely high compute) tasks to a heavy iron server they dedicated to such work. They were using SOAP and having a very difficult time getting all the pieces and parts to work. At the time, Drupal 6 (a PHP web framework that used to be popular) had just released a "Services" module/plugin that enabled one to add a REST Service to any Drupal site. Working with them to initially understand what the SOAP tooling required, and then comparing that to what that REST Services Module required was a no brainer. They had a team of 11 people working on the SOAP infrastructure, and they were all super happy to ditch it and get back to their real work. Re-writing as a RESTful API using Drupal Services merely as a bureaucrat to communicate with their heavy iron server only required myself and one other programmer I brought with me. About 3 weeks later we completely replaced their SOAP infrastructure. For years afterwards, I'd check in on them and it just worked.
  - toyg 5y ago
    The mistake of SOAP specs was to believe toolmakers were on their side, and tooling would magically solve all problems so that you would never actually have to look at what went down the wire. Whereas toolmaking companies were only on the side of making money, and looking down the wire was often unavoidable. REST went back to basics, simple protocols that humans could work on with little more than a text editor.
elzbardico 5y ago
Frankly, years ago, when reading it, I got the same idea, but promptly dismissed it because it couldn't be the case that all that people got it wrong and I was right.
bob1029 5y ago
The way I see things now: - Avoid this entire conversation if you can (web only, blazor, live wire, business constraints, etc.) - Use JSON if your API is exposed to the general public. Keep the nesting of complex types to a minimum, preferring to reference nested items by identity rather than placing them inline. - Use out of band mechanisms if your API is very complex and/or shared between business entities only. Example of this being SOAP/XML. We have been consuming WSDL files for purposes of integrating with a complex banking system. I would argue that JSON would make our jobs much harder in this particular case. The primary reason I don't like the XML path is because of the up-front schema sharing session. Once you get over this and run your codegen, life is actually really easy. For example, I enjoy having my compiler yell at me when I try to send a string vs a Datetime to a vendor endpoint.
- jrochkind1 5y ago
  GraphQL?
  - stuff4ben 5y ago
    That's what I'm thinking too. GraphQL for the frontend, gRPC for backend to backend.
    - 89vision 5y ago
      I really like gRPC. I've even worked with a browser implementation of it. SerDe costs were painful but the developer experience of it was great
- gautamdivgi 5y ago
  gRPC if you need some sort of static typing over https and don't want vendor lock-in. SOAP/XML works too. It's been a while since I looked which open source toolkit supported it. Problem with SOAP/XML is that although its not supposed to be "Java specific" it is mostly "Java specific".
dekhn 5y ago
what's funny is while REST is so badly conceptualized the underlying concept of using simple http with headers and a json payload to implement RPC is a very good one. That said I think XDR based approaches (everything from original Sun XDR to protobuf/grpc) are far better because the idea of passing API calls through HTTP proxy layers is kinda crazy.
DeathArrow 5y ago
If databases were invented in 2020 instead of using an old fashioned binary protocol using a socket we would be using an "RESTFul" interface. So wo would use PUT /Students and GET /Students/id and POST /Queries?parameter=SELECT%20%2A%20FROM%20STUDENTS%20WHERE%20NAME%20%3D%20%27John%27
DeathArrow 5y ago
Following "REST" or "FIOH" we actually follow the principles of Execution in the Kingdom of Nouns[1]. REST is to APIs what OOP is to programming: something that is unnecessary and forcefully used by anyone in all those places it really shouldn't and for the wrong reasons. [1] https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
- Chris2048 5y ago
  But what is the 'functional programming' of APIs?
  - DeathArrow 5y ago
    I think RPC might be closer to that. Apache Thrift, grpc and the likes.
mherdeg 5y ago
Ten years back I looked into drafting a RESTful API for a mature software server that didn't expose yet a public API. What I did was read Roy Fielding's thesis then try to apply REST from first principles to our services, sketching out an API pattern that complied with the best-practices he outlined. It quickly became apparent that a couple of things were very weird: (1) trying to reimagine our very stateful application in a stateless way was a BIG change for "let's add an API" work (2) trying to make it so that the client could enter the API with no knowledge of the initial URI, and find every other possible interaction using links provided by API responses, was pretty ambitious In retrospect what I probably should have done was rounded up a dozen potential API developers and interviewed them about the problems they expected to need to solve using the feature, then designed something that met their needs, rather than trying to build to Fielding's spec just because the feature request said "please build a REST API" and that's what a REST API is.
munificent 5y ago
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. 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. This problem is endemic in software architecture. Every time I read a criticism of Design Patterns most of the complaints about it echo text literally in the book itself. Each design pattern chapter has a long list of reasons why not to use it, but somehow that gets lost in translation.
recursivedoubts 5y ago
REST doesn't make much sense outside of the context of it's original environment: coarse grain hypermedia systems. It was cargo-culted into first the SOAP API world and then, more humorously, into the JSON API world. Goes to show how much more institutional momentum matters than common sense in technical questions. Even granting XML and JSON could have a hypermedia imposed on top of them, if it is code, rather than a human, consuming the API, all the dynamicism of the uniform interface is wasted. HATEOAS is for humans: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
gumby 5y ago
> 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… Ah, how science used to be done (actually by 2000 this was rare too). If you look up the original (computer) mouse paper you’ll see that the mouse was just invented on the fly bc they were trying to see if a trackball or pen digitizer (light pen — hold up to the CRT) was the better pointimg device. But an n of two was too small so they made a couple of others (I liked the broomstick hanging under the table) and the mouse was a throwaway example that actually turned out to be the best. I asked Engelbart about this once and he said this was in fact the case. He invented quite a few unusual input devices. (Perhaps cursor keys were in there too? I can’t remember)
eternalban 5y ago
The implicit and generally overlooked actor of the REST based systems is the client. REST requires a semantic client that reads the provided resource lists. The germinal idea behind REST was an appreciation of WWW as an ad hoc distributed system resilient to various fault modalities where unknown clients collaborated with known servers, using only a hypertext protocol. How did this work and how can it be generalized? That is the REST dissertation. A REST system for domain X naturally requires design for a finite state machine client that can infer semantics for the resources in domain X. In general WWW, the client is a browser + a human being that reads links. Once you remove the human semantic processor of this equations while retaining capability, the client rapidly increases in complexity, if at all possible. Is it natural to think of ("mutating stateful!") systems? It is difficult and somewhat out of phase to be server centric. But if you think in terms of a smart client for domain X, map out the app's capabilities, and then map resources in domain X you need to fulfill capability C, then REST is a perfectly natural way to consider systems, in an end-user centric approach to system design, for a specific domain.
vjust 5y ago
I dreaded SOAP, and how it seemed to spawn an industry . I dreaded having to answer SOAP related questions in job interviews, but more than that I dreaded using any form of SOAP in my day-to-day work. Its nice our industry consigns certain technologies into their place on the sidelines. Not to say we still have many others that are a burden on the developer, and the organization in general.

197 points by fagnerbrack 5y ago

This article is timely, thanks. I'm learning this stuff at the minute. And based on the description provided of REST I couldn't marry it up what what the course was later describing as REST. This article has made sense of that for me.

DeathArrow 5y ago

>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 That's somewhat ironic given that anybody is using "RESTful" APIs now.

DeathArrow 5y ago

Long story short: -if you are designing a public API it might pay to make it "RESTful" and even use HATEOAS -if your API isn't public, the it might be better to find a schema that better fits your particular problem -if your clients aren't browsers - there's nothing to gain by using RSET, HTTP and JSON, apart from familiarity.

Semaphor 5y ago

Last year, 179 comments: https://news.ycombinator.com/item?id=23670238 https://news.ycombinator.com/item?id=23670238

beachy 5y ago

HATEOAS has never really grabbed me. Not least because, despite HN now swung hard against microservices, they exist often for a reason, and it's difficult for one service to emit hypermedia for another. The inspiration was humans surfing freely through interlinked web pages, but API clients just don't naturally do that.

bryanrasmussen 5y ago
I always understood application in HATEOAS to be referring to the browser or whatever type of application sitting on some machine somewhere had been written to consume hypertext, but it sounds like you're considering a service to be the application?
- beachy 5y ago
  I was referring to something like this. Here's a hypermedia API entry point I googled up. GET / { "version": "1.2.3", "description": "Example API to manage orders", "links": [ { "rel": "orders", "href": "/orders" }, { "rel": "customers", "href": "/customers"}, { "rel": "customer-by-id", "href": "/customer/{id}"}, { "rel": "customer-by-email", "href": "/customer{?email}"}, ... ] } My point was, how is such an API served up when it spans resources that are managed by two separate services / microservices - one for customers, one for orders? Of course this is a simple example, we are smart tech heads, so obviously we can wedge a third service in front of the other two, which exists solely to provide aggregating behavior like this. But why? Is hypermedia so useful that it's worth going to this trouble? (No IMHO).
  - eyelidlessness 5y ago
    Django REST Framework (and I’m assuming later work by its authors) get this right and literally populate URLs rather than giving you patterns.
    - beachy 5y ago
      Not familiar with Django sadly but it sounds like it would act as something of a proxy that sits in front of your microservices. My point is that if you are starting with just e.g 2 microservices, one for customers, one for orders, then hypermedia on it's own is not useful enough to justify adding a new proxy/ layer, just so that an API produced by one of those microservices can include hypermedia for the other.

quantified 5y ago

FIOH is a great addition to the lexicon.

Toutouxc 5y ago
I wouldn't mind using "FIOH API" instead of "well the API is RESTful, I mean, it isn't really RESTful, but we use HTTP methods on resource-based endpoints and a couple of HTTP status codes to represent our mostly CRUD-ish actions".

deleted 5y ago

[deleted]

ramesh31 5y ago

REST is far too narrow to fully encapsulate the features necessary in even the most basic of web apps. A truly RESTful API is essentially just a database. So application backends always ends up being a JSON RPC API over HTTP. Better to formalize that with an RPC framework than zealously attempt sticking to something that is inadequate.

eyelidlessness 5y ago
I’m disappointed to see this comment. What don’t you think can be expressed with REST that can be with RPC?
- lmm 5y ago
  Custom verbs. REST is a recapitulation of "Execution in the Kingdom of Nouns" as a network metaprotocol rather than a programming language.
  - rswail 5y ago
    YAGNI most of the time. Custom verbs change the focus to the verb. The verb is not visible because it's ephemeral during the "call". Whereas the state of the Noun is clear. Verbs are also not idempotent for the most part, whereas it's relatively easy to ensure that the non-idempotent HTTP verbs (POST, PUT/PATCH, ignoring DELETE) can be made "repeatable" with use of etags or other unique identification.
    - lmm 5y ago
      > Custom verbs change the focus to the verb. Which is often what you want - a lot of things in the real world are more easily understood through verbs than nouns, which is what the essay is all about. REST says that everything has to be an entity, which is why so many "REST" APIs end up just exposing their database as CRUD rather than offering a vocabulary that actually makes sense for the domain. When nouns are the only important things in your domain then it works. When verbs are important in your domain it doesn't. > it's relatively easy to ensure that the non-idempotent HTTP verbs (POST, PUT/PATCH, ignoring DELETE) can be made "repeatable" with use of etags or other unique identification. Most "REST" APIs "in the wild" don't actually do that (or, worse, do it incorrectly), so I'd question the idea that it's actually easy in practice.

eyelidlessness 5y ago

Ugh. REST and HATEOAS are just, only just: 1. an affirmative statement that HTTP semantics are mature and robust enough to express networked application communication 2. that using those semantics is better than not, when communicating over HTTP This shouldn’t be controversial! Want GraphQL? Cool, ?foo[bar]=quux. Want a special data transport format? Cool, Content-Type: application/furby. Want a big blob of different content? Multipart has your back. There’s nothing special about REST. Use the format! The only special thing is you have to… use it. POST / everything ain’t that. Sure it’s convenient for your custom format that doesn’t interop with anything. And then it’s a decade of articles about no one using common standards. Welp, this standard was here all along.

lmm 5y ago
> Ugh. REST and HATEOAS are just, only just: > 1. an affirmative statement that HTTP semantics are mature and robust enough to express networked application communication > 2. that using those semantics is better than not, when communicating over HTTP No they're not. Read the dissertation. HATEOAS is a specific thing and using HTTP semantics doesn't mean you're doing HATEOAS. The article is completely right; what you're advocating for is FIOH.
pornel 5y ago
Clarifications from Roy himself: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... • A REST API should not be dependent on any single communication protocol • A REST API must not define fixed resource names or hierarchies • A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) • A REST API should spend almost all of its descriptive effort in defining the media type This is the exact opposite of what people usually do and call it "REST": a predefined URL scheme for JSON tied to HTTP semantics (this not to say that Roy's REST is in any way better; JSON over HTTP is nice. It's just funny that popular definitions of REST have flipped 180°).
- regularfry 5y ago
  Also a useful reference: https://martinfowler.com/articles/richardsonMaturityModel.html https://martinfowler.com/articles/richardsonMaturityModel.ht...

RandyRanderson 5y ago

SOAP, REST, Big Data, microservices - it's funny how, at the time, everyone seems to be unbelievably vociferous that <technology_of_the_moment> is the only way to do things and that we should all be thankful that the great magnet in the sky gave us this sacred cow. Then, 5 years later, it's obviously the worst thing ever next to the <new_hotness>. <new_hotness> always being unevenly in some ways worse and in others better. We need to, in our exuberance, ask ourselves: what are the current false Gods? Are we technologists that reason or a headless flock?

brylie 5y ago
AWS Lambda?
rswail 5y ago
REST was never about "technology", it's about an architectural style that is particularly suited to a networked separation of API consumers and producers. SOAP was an overengineered set of "standards" that had enough wiggle room that none of the SOAP implementation would interoperate correctly. "microservices" are just "services". The technology that allows them, also allows for horizontal scaling, especially if you ensure that your API is stateless (not the resources, by definition, they have state, that's what you're "transferring"). I've been doing this stuff for 30 years now, and the more things change, the more they stay the same. IMNSHO, the current false Gods are all the "cloud" items. The infrastructure stuff in AWS/GCP/Azure is just... networking and servers with APIs on top. There's nothing particularly special, except that the APIs let you avoid thinking about the underlying infrastructure. As the cloud climbs the software stack, from IaaS, to PaaS (eg RDS), to SaaS (eg Stripe), it's interesting that the APIs remain primarily HTTP/JSON (or XML) and "RESTful" for the most part.
DeathArrow 5y ago
People would use what is trendy because they think doing so it's safer, brings them more jobs and has support.

deleted 5y ago

[deleted]

rswail 5y ago

Yes, Fielding's dissertation backronymed the HTTP protocol into REST, but the concept of resource driven design also exists. The benefits of applying the REST style is: 1. Limiting the verbs makes you focus on the nouns (URIs) and the description of them. 2. REST verbs do NOT "map" to CRUD in a database. This is overloading the REST style to match a server's implementation. What or how a server (or client) maintain the state of a resource is up to that server/client. 3. HATEOAS is not really achievable for naive clients. Browsers "expose" the links to the human user to enable the user to navigate. HTML provides the particular media type to expose that navigation. 4. If a server and clients agree on a media type, then as part of that agreement is the interpretation of attributes, like "link" elements with "rel" and "href" attributes. 5. RPC (whether as ONC-RPC, CORBA, XML-RPC, JSON-RPC) etc is brittle. It usually requires both the client and server to upgrade their understanding of the interface simultaneously and makes it hard to version or separate the system elements. This lesson has to be learned over and over as programmers realize that "remote" procedure calls are not local and can't use the same semantics. 6. The process I've followed (successfully) is: * Define a "well known" URL. I use "/versions" that returns a media type that describes the available API versions, attributes of them like "not before" and "not after" and a versioned endpoint for subsequent usage. This allows clients and servers to evolve independently. The versions follow semver, so it's clear when there's breaking and non-breaking changes. * Define resources in terms of their state (via a FSM) and transitions. Map the transitions to HTTP verbs, along with media types that describe the change in state. * The transitions should be expressed in terms of the resource, not CRUD. Don't talk about "Create Account", you "open" an account. In business terms, it is very rare that you "delete" something. In addition, HTTP semantics means that you can't return a message body for the DELETE verb. * Using PUT vs PATCH can be avoided by exposing the things that you want to "PATCH" via sub-resources in the URL pattern (or appropriate HREFs in the parent resource). Including the sub-resource attributes in the parent (when you GET it for example) should be selectable via a query parameter on the GET. However, where possible, use GETs of the sub-resources and cache them appropriately. The net result is that you have an API that is consumable mostly automatically, with the agreed media types defining the necessary navigation. I've never used downloadable code as it hasn't been necessary, but it's relatively easy to see how to extend the media types to include links to the code (ie the equivalent of <script> tags). Unfortunately protobufs have re-introduced the concept of RPC style APIs and they absolutely suck, even if protobuf does allow you to version the messages. You still need to exchange the proto headers and recompile code to update. It's still brittle RPC underneath, because programmers can't be assed dealing with network failures or other issues or with proper internal versioning of the underlying implementations. There's really no need for most use-cases to use anything other than HTTP, the standard verbs and their interpretation, URLs (potentially with patterns but avoidable with proper links), and JSON media types/schemas. Compression of the JSON makes it mostly equivalent to protobuf on the wire, HTTP/2 etc avoids the single threaded nature of the HTTP TCP connection.

rswail 5y ago

Back in the day, I was on a yahoo group that had the REST evangelists pushing for how REST maps much better to consumable APIs than the enterprise nonsense that SOAP/WSDL/WS-* and all that created. The SOAP people disagreed because they wanted everything defined up front between parties, out of band and then the enterprise companies started selling "tooling" to over-engineer and "manage" this nonsense. Soon there was "governance" introduced so that centralized control of APIs could be configured and managed. Of course, the different implementations couldn't interoperate, so there was classic "supplier lockin" to your chosen Enterprise-Ready WS-* infrastructure (tm). WS-Addressing introduced resource addressing over XML over HTTP that overloaded the equivalent of a URL. Just one example. REST in general (HTML/JS/HTTP in particular) has proven to be scalable, understandable, and implementable, without all the associated nonsense that WS-* dragged in. Want encryption in transit? TLS provides that. Want caching of results on either client or server or intermediate? HTTP Etags and headers provide that. About the only thing that REST over HTTP doesn't provide is sessions, but JWTs and OAuth now handle most of that.

andrewf 5y ago
My favorite WS-* is WS-I, a bunch of guidelines about which versions/subsets of the other standards to use, if you actually want to talk to someone else. (As someone who once had to implement a SOAP server supporting diverse clients, I'll never pass up a chance to get a dig in)
- function_seven 5y ago
  I remember the time someone told me what the "S" in SOAP stood for. They were clearly pranking me; I refused to believe it. And to this day, nobody will give me the real answer! Whole world is in on this prank, and I've given up trying to find out.
  - wsc981 5y ago
    Obligatory reference “S Stands For Simple: http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple

posharma 5y ago

With the popularity of grpc and thrift I've not seen many cases where REST is needed for internal communication. I understand it's required for external communication though. Grpc and thrift are kind of the opposite direction APIs are taking (or have already taken) as in don't we hate RPCs? We do but speed and efficiency are much more important for internal comm (and binary protocols are just one of the factors at play here).

jseban 5y ago
Yeah, it's designed for discoverable APIs on the open internet, why use it for internal communication I have no idea. All the time I've wasted making apps slower and worse, and arguing over it, just because it's the "correct" RESTful way, and creating and maintaining documentation, when there's only one single client, and it's also managed in the same team. It just becomes a line drawn in the code in a random place where everything becomes more difficult, dogmatic and impractical.
- DeathArrow 5y ago
  >why use it for internal communication I have no idea Here are a few potential reasons: 1. HTTP is familiar 2. RESTful seems easy 3. people are told that RESTful is the way to go, is cool is mainstream and is modern

shadeslayer_ 5y ago

"..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." This bit is particularly important to me personally because I have been that guy in the past. As a new grad fresh out of college, someone taught me REST and I was.. impressed. I thought it was the only way to design web backends. It was my hammer and everything else I saw was a nail. A few years on, I can look back and understand how stupid I was.

M0r13n 5y ago

Building a proper rest API is pretty hard. I think I speak for many developers when I say that I limit myself to the most important core statements. For most applications, a simple API + HTTP + sensible url scheme is completely sufficient. Especially when the API doesn't need to be publicly consumable. The author himself says that as a good designer you should select a style that matches the needs of a particular problem being solved. Things like URL Autodiscovery are definitely desirable from an idealistic or academic point of view. However, I have never seriously needed such features.

jseban 5y ago
> Things like URL Autodiscovery are definitely desirable from an idealistic or academic point of view. However, I have never seriously needed such features. Yeah I'm so tired of this bs from developers who treat their jobs as an idealistic academic exercise instead of doing what makes sense for the organisation. They don't work for Roy Fielding for christ's sake, so why are they spending so much time and effort supporting his research?

hyperpallium2 5y ago

The only benefit of REST is caching.

streamofdigits 5y ago

I wonder if the reason HATEOAS is not taken more seriously / developed further is simply the economic / cultural context of the dominant style of software development during the past decade (centralization, winner-takes-all, command-and-control etc) rather than something intrinsic about the architecture A decentralized web (as originally imagined) involves countless diverse servers and clients exchanging data of constantly evolving (as in: growing in complexity) semantic structures. What is needed is not inventing a "language to rule all languages" but inventing the dictionary. If there is an alternative pattern that can somehow enable a truly functional decentralized web please step forward.

regularfry 5y ago
XHTML. Seriously. If what you want looks like an extensible document type with custom embedded data that you want to reliably parse out, that's what it's there for.
- streamofdigits 5y ago
  the "X"(ML/HMTL/...) universe seems to have been deprecated but lots of boring people out there that need to manage real life complexity seem to wonder the wisdom of the "in crowd" progress has sometimes a strange "helix" like structure: revisiting and re-using valuable old patterns after fixing their pain points
DeathArrow 5y ago
I don't know about the others but I don't use HATEOAS because 1. is simpler not to and 2. I don't have a need for it
jrochkind1 5y ago
I think you're right, but I also think the cause-and-effect is pretty bilateral. Designing implementing and maintaining that kind of decentralized HATEOS/"semantic web" (there's a simlarity, right?) infrastructure, in a way that actually works well... is very expensive. More expensive than it's (non-"political"[1]) benefits. People do things where the immediate benefit is worth the immediate cost. That is, there is something intrinsic about the architecture that is both suitable to decentralization, and more complicated/expensive for not enough obvious benefit to those who pay the expense. And these are related. [1] "political" in the sense of "where the power lies". And they are real benefits there to decentralized infrastructure (at least for those who aren't going to be in the center). But the way our economy and society works, they don't produce funding to create.

austincheney 5y ago

There were two key discoveries that Fielding proposed regarding URI, one of which is REST. The other is that URI may serve as a universal unique identifier that works regardless of whether a resource is resolved to a given address.

throw_m239339 5y ago

I just moved everything to basic JSON RPC with GET and POST when I'm not using GraphQL. Etags are useful for caching and that's basically it. Fielding dissertation is a fantastic academic exercise, but I don't have time to debate the "true meaning of REST" with my coworker, like I did for 15 years. remote API are no different from libraries, you can use semvers to version them it's up to the client to detect whether the API breaks at some point or not. As for the idea of resource based design, HATEOAS and "smart clients", it's as dead as the semantic web.

lloydatkinson 5y ago
Yes this is my thoughts too. Though I include a DELETE in that small list. Seriously, it's been years and years and people still don't know what REST actually is. Neither do I, because everyone else gives a different explanation. It's a mess.
acdha 5y ago
> Fielding dissertation is a fantastic academic exercise, but I don't have time to debate the "true meaning of REST" with my coworker, like I did for 15 years. I think this is a very true point: GraphQL certainly has analogous challenges but doesn’t seem to have developed the quasi-academic cult debating how many angels can dance on the head of a pin[1]. I remember so many pointless arguments that something had to be built in a theologically-correct manner even if it wasn’t a natural fit for the problem and there was no known user who wanted that behavior. 1. As with other things like Agile, this isn’t a criticism of Fielding but rather what came after that success, especially the people who wanted to talk like academics without attempting the rigor.
- naasking 5y ago
  > I remember so many pointless arguments that something had to be built in a theologically-correct manner even if it wasn’t a natural fit for the problem I don't think most of the arguments were about building something RPC-like, the people complaining were just saying "stop calling RPC APIs REST", and that's perfectly reasonable. REST is totally not just RPC over HTTP.

jensneuse 5y ago

My personal take, don't decide between REST, SOAP, GraphQL, etc.. to build APIs but rather combine the best of all of them. I wrote about this topic a while back: https://wundergraph.com/blog/the_fusion_of_graphql_rest_json_schema_and_http2 https://wundergraph.com/blog/the_fusion_of_graphql_rest_json...

virtualritz 5y ago

> This is the deep, deep irony of REST’s ubiquity today. REST gets blindly used for all sorts of networked applications now [...] This. I don't even know where to start if I were to talk about the idiocy behind stateless networked apps on my phone. My fav. example are car/scooter sharing apps. Some even 'forget' the map tiles between screen locks. But pretty much all of them 'forget' your active booking. And the route to the vehicle. Which is just great when you are walking from a party (where you had the host's WiFi to do the booking) in a neighborhood with shitty mobile network, in Winter. For something like ShareNow it can take up to three minutes on an 'E' connection to load missing map data, active booking and route to car. If your phone locks screen during that time ... just unlock and ... wait another three minutes. You may have guessed that I'm talking first hand experience here. Frequently so, ofc. I'm using these apps heavily here in Berlin, since 2014. It's the reason I bought gloves that let you use a touchscreen. Not kidding. Even though it's valid for 20 minutes and the likeliness of the the vehicle becoming unavailable due to reasons outside of the user canceling the booking or changing the phone's system time are pretty much non-existent even this info is not retained on the Phone. Because that would entail state. The idea that the network interface of an app can be RESTful yet the app itself can carry state and cache stuff on the phone – and that is A-OK – seems absent from the minds of whoever develops this. EDIT: typo(s)

twic 5y ago
These apps are poorly written, but this has nothing to do with REST, or HTTP being stateless. Indeed, HTTP being stateless forces apps to implement state management which can naturally survive network interruptions. If the apps you are complaining about used a stateful protocol, they would be even worse!
- virtualritz 5y ago
  Maybe you misread me. I said the the protocol can be stateless but the app itself, towards the user, should carry state – where this makes sense. E.g. in the cases I described.
alangibson 5y ago
I'm not saying REST is the right approach to the apps you describe, but nothing you're describing is a REST issue per se. You're describing incompetent handling of network disconnects, cache invalidation and many more. Theses are issues that plague all distributed systems.

throw0101a 5y ago

> 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 I'd be curious to see a web without cookies. I understand the desire for stateless, but given how many things need logins and an user "session" how would that work without cookies?

DeathArrow 5y ago
>I understand the desire for stateless, but given how many things need logins and an user "session" how would that work without cookies? RESTful is ok for public APIs. If you design both the client and server, you don't need to be stateless.
- jseban 5y ago
  > If you design both the client and server, you don't need to be stateless. And you also don't need to be RESTful.

DeathArrow 5y ago

>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. Are there know architectural models better suited to build microservices? GraphQL, grpc are constructed on top of HTTP which according to the article uses REST as inspiration.

rswail 5y ago
grpc is RPC. It's in the name.
- DeathArrow 5y ago
  Yes, but relies on HTTP.

DeathArrow 5y ago

Working on a big microservice solution right now, it amazes me how inefficient we are: we are making HTTPL calls, replying HTTP calls, serializing data to JSON, deserializing data from JSON in a long chain of calls. I rather see a distributed application the same way as I see a monolithic application: I don't want to make HTTP calls, I don't want to serialize JSON, what I want is to call remote functions with my local data in a reliable, fast and efficient way. It seems weird that we can't just do that and instead we pack the data in layers upon layers, thus decreasing performance and increasing complexity a bit.

coredog64 5y ago
Same: At one point, we analyzed our app and determined that about half the assigned compute was being used for serializing and deserializing JSON. If the project wasn’t also years late they would have moved to Protobuf and saved millions.
- naasking 5y ago
  Or use Cap'n Proto [1] and eliminate all serialization costs. [1] https://capnproto.org/ https://capnproto.org/

mcherm 5y ago

The article writes: > 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 First of all, I fully agree with this article. I lived through this transition and my own reasoning is well as that of basically everyone I talked to was really just that the existing infrastructure was overly complicated, while "just passed some JSON over HTTP" was easy. I do, however, want to disagree with one point quoted above. The proxying and caching support were not the reasons why FIOH was based on HTTP. The reason was firewalls. At first, almost all of the things I built and almost all of the RESTful APIs I saw published, were really just some form of remote procedure call. Caching was supported in theory but hardly ever used in practice. However, it was policy pretty much everywhere to have firewalls that blocked traffic to most ports other than 80 and 443. The more advanced firewalls also verify that traffic over those ports was actually HTTP traffic. So it wasn't possible to build any kind of an API that wasn't based on HTTP -- it would have been impossible to deploy and use without getting permission from the firewall and security teams on both the client and server and of the connection.

fieldcny 5y ago
This was my experience as well, trying to convinced enterprise security folks to let new protocols through firewalls was nearly impossible. The difficulty was exponentiated for api/service calls inbound to the organization. SOAP services, even though they went over http, had to go through special inspection devices because XML parsing libraries were so complex and prone to parsing issues and security vulns.
- voakbasda 5y ago
  > SOAP services, even though they went over http, had to go through special inspection devices because XML parsing libraries were so complex and prone to parsing issues and security vulns. So did the person who ordered that inspection device realize that the SOAP streams under inspection would be examined using a set of XML parsing libraries that are complex and prone to vulnerabilities? Seems like this setup just creates another device that must be maintained. Perhaps the solution would be to use another machine to inspect the inspection devices. Turtles all the way down.

jrochkind1 5y ago

> 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) Having been a developer during that period of history, I'd say OP gets it about right, that's what happened. For better or worse; it's not obvious to me that it was a poor choice. I do agree it somewhat misappropriated the "REST" term and misrepresented itself as being more "standardized" than it was -- also for more or less the reasons OP suggests: "that would have seemed recklessly blasé next to all the formal specification work that went into SOAP… a veneer of academic respectability". Although I do recall some people right from the start really were interested in HATEOAS and trying to do it... I think it's practical benefits were somewhat elusive. It reminds me of "semantic web" in some ways, not sure if that makes sense...

bsenftner 5y ago
I remember consulting for a tech company around '07 that needed to send remote (extremely high compute) tasks to a heavy iron server they dedicated to such work. They were using SOAP and having a very difficult time getting all the pieces and parts to work. At the time, Drupal 6 (a PHP web framework that used to be popular) had just released a "Services" module/plugin that enabled one to add a REST Service to any Drupal site. Working with them to initially understand what the SOAP tooling required, and then comparing that to what that REST Services Module required was a no brainer. They had a team of 11 people working on the SOAP infrastructure, and they were all super happy to ditch it and get back to their real work. Re-writing as a RESTful API using Drupal Services merely as a bureaucrat to communicate with their heavy iron server only required myself and one other programmer I brought with me. About 3 weeks later we completely replaced their SOAP infrastructure. For years afterwards, I'd check in on them and it just worked.
- toyg 5y ago
  The mistake of SOAP specs was to believe toolmakers were on their side, and tooling would magically solve all problems so that you would never actually have to look at what went down the wire. Whereas toolmaking companies were only on the side of making money, and looking down the wire was often unavoidable. REST went back to basics, simple protocols that humans could work on with little more than a text editor.

elzbardico 5y ago

Frankly, years ago, when reading it, I got the same idea, but promptly dismissed it because it couldn't be the case that all that people got it wrong and I was right.

bob1029 5y ago

The way I see things now: - Avoid this entire conversation if you can (web only, blazor, live wire, business constraints, etc.) - Use JSON if your API is exposed to the general public. Keep the nesting of complex types to a minimum, preferring to reference nested items by identity rather than placing them inline. - Use out of band mechanisms if your API is very complex and/or shared between business entities only. Example of this being SOAP/XML. We have been consuming WSDL files for purposes of integrating with a complex banking system. I would argue that JSON would make our jobs much harder in this particular case. The primary reason I don't like the XML path is because of the up-front schema sharing session. Once you get over this and run your codegen, life is actually really easy. For example, I enjoy having my compiler yell at me when I try to send a string vs a Datetime to a vendor endpoint.

jrochkind1 5y ago
GraphQL?
- stuff4ben 5y ago
  That's what I'm thinking too. GraphQL for the frontend, gRPC for backend to backend.
  - 89vision 5y ago
    I really like gRPC. I've even worked with a browser implementation of it. SerDe costs were painful but the developer experience of it was great
gautamdivgi 5y ago
gRPC if you need some sort of static typing over https and don't want vendor lock-in. SOAP/XML works too. It's been a while since I looked which open source toolkit supported it. Problem with SOAP/XML is that although its not supposed to be "Java specific" it is mostly "Java specific".

dekhn 5y ago

what's funny is while REST is so badly conceptualized the underlying concept of using simple http with headers and a json payload to implement RPC is a very good one. That said I think XDR based approaches (everything from original Sun XDR to protobuf/grpc) are far better because the idea of passing API calls through HTTP proxy layers is kinda crazy.

DeathArrow 5y ago

If databases were invented in 2020 instead of using an old fashioned binary protocol using a socket we would be using an "RESTFul" interface. So wo would use PUT /Students and GET /Students/id and POST /Queries?parameter=SELECT%20%2A%20FROM%20STUDENTS%20WHERE%20NAME%20%3D%20%27John%27

DeathArrow 5y ago

Following "REST" or "FIOH" we actually follow the principles of Execution in the Kingdom of Nouns[1]. REST is to APIs what OOP is to programming: something that is unnecessary and forcefully used by anyone in all those places it really shouldn't and for the wrong reasons. [1] https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

Chris2048 5y ago
But what is the 'functional programming' of APIs?
- DeathArrow 5y ago
  I think RPC might be closer to that. Apache Thrift, grpc and the likes.

mherdeg 5y ago

Ten years back I looked into drafting a RESTful API for a mature software server that didn't expose yet a public API. What I did was read Roy Fielding's thesis then try to apply REST from first principles to our services, sketching out an API pattern that complied with the best-practices he outlined. It quickly became apparent that a couple of things were very weird: (1) trying to reimagine our very stateful application in a stateless way was a BIG change for "let's add an API" work (2) trying to make it so that the client could enter the API with no knowledge of the initial URI, and find every other possible interaction using links provided by API responses, was pretty ambitious In retrospect what I probably should have done was rounded up a dozen potential API developers and interviewed them about the problems they expected to need to solve using the feature, then designed something that met their needs, rather than trying to build to Fielding's spec just because the feature request said "please build a REST API" and that's what a REST API is.

munificent 5y ago

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. 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. This problem is endemic in software architecture. Every time I read a criticism of Design Patterns most of the complaints about it echo text literally in the book itself. Each design pattern chapter has a long list of reasons why not to use it, but somehow that gets lost in translation.

recursivedoubts 5y ago

REST doesn't make much sense outside of the context of it's original environment: coarse grain hypermedia systems. It was cargo-culted into first the SOAP API world and then, more humorously, into the JSON API world. Goes to show how much more institutional momentum matters than common sense in technical questions. Even granting XML and JSON could have a hypermedia imposed on top of them, if it is code, rather than a human, consuming the API, all the dynamicism of the uniform interface is wasted. HATEOAS is for humans: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

gumby 5y ago

> 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… Ah, how science used to be done (actually by 2000 this was rare too). If you look up the original (computer) mouse paper you’ll see that the mouse was just invented on the fly bc they were trying to see if a trackball or pen digitizer (light pen — hold up to the CRT) was the better pointimg device. But an n of two was too small so they made a couple of others (I liked the broomstick hanging under the table) and the mouse was a throwaway example that actually turned out to be the best. I asked Engelbart about this once and he said this was in fact the case. He invented quite a few unusual input devices. (Perhaps cursor keys were in there too? I can’t remember)

eternalban 5y ago

The implicit and generally overlooked actor of the REST based systems is the client. REST requires a semantic client that reads the provided resource lists. The germinal idea behind REST was an appreciation of WWW as an ad hoc distributed system resilient to various fault modalities where unknown clients collaborated with known servers, using only a hypertext protocol. How did this work and how can it be generalized? That is the REST dissertation. A REST system for domain X naturally requires design for a finite state machine client that can infer semantics for the resources in domain X. In general WWW, the client is a browser + a human being that reads links. Once you remove the human semantic processor of this equations while retaining capability, the client rapidly increases in complexity, if at all possible. Is it natural to think of ("mutating stateful!") systems? It is difficult and somewhat out of phase to be server centric. But if you think in terms of a smart client for domain X, map out the app's capabilities, and then map resources in domain X you need to fulfill capability C, then REST is a perfectly natural way to consider systems, in an end-user centric approach to system design, for a specific domain.

vjust 5y ago

I dreaded SOAP, and how it seemed to spawn an industry . I dreaded having to answer SOAP related questions in job interviews, but more than that I dreaded using any form of SOAP in my day-to-day work. Its nice our industry consigns certain technologies into their place on the sidelines. Not to say we still have many others that are a burden on the developer, and the organization in general.