14 ms·

Should we rebrand REST?

123 points by bshanks 5y ago

kuu 5y ago
TLDR: REST != web service APIs
- cryptos 5y ago
  That is exactly the point! Most people talking about "REST" are just talking about web service APIs or HTTP APIs, because they are not aware of the actual meaning. REST became a shallow term.
rualca 5y ago
It makes absolutely no sense to even suggest that REST should be rebranded "HTTP API" or even "hypermedia API" because REST is neither protocol-specific nor is "hypermedia" the only (or even main) design trait. It's like someone who is entirely unfamiliar with REST feels compelled to make bold statements about traits he doesn't fully grasp.
- masklinn 5y ago
  > nor is "hypermedia" the only (or even main) design trait. If you take REST as what it’s original author defined, then it absolutely is. Fielding literally has an article saying so: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... > REST APIs must be hypertext-driven If you take REST as what it’s become (a worthless buzzword for HTTP-based APIs) then > REST is neither protocol-specific Is wrong in turn. You can’t deny both. Unless you’ve decided to make it even more worthless and just a synonym for « API » I guess.
  - rualca 5y ago
    > REST APIs must be hypertext-driven That's a reference to HATEOAS, but the whole point is that REST refers to an entire collection of design traits, where hypermedia is only one of them, and you cannot have REST if you do not meet other design requirements first, such as resource-driven architecture. Making REST all about HATEOAS is almost as bad as making REST all about hard coded paths to resources. > If you take REST as what it’s become (...) REST didn't became anything. It has always been the same thing. It's specification is set in stone in the doctoral thesis, and complemented with subsequent posts and public statements from the author. This sort of post has nothing to do with REST at all. It has zero to do with technology or design. This is vacuous and baseless buzzword bingo that adds nothing of value and just manifest a fundamental misunderstanding of the subject that is intended to be discussed. We already have RPC-over-HTTP. It's not REST, everyone knows that. That's a very old concept, as is the resistance to implement HATEOAS. There is nothing of value in this. It's just a clear sign that the author jumped to the part where he feels compelled to coin buzzwords by appropriating established and well-defined concepts while skipping the part he gets acquainted with the subject, thus showing a fundamental misunderstanding of the whole topic.
  - jayd16 5y ago
    >A REST API should not be dependent on any single communication protocol I think hypertext is wider than HTTP as far as this blog post in concerned.
    - masklinn 5y ago
      > I think hypertext is wider than HTTP as far as this blog post in concerned. Yes? Did you wildly misread my comment? REST is either the original definition, in which it is hypertext-driven and protocol-agnostic, or a worthless buzzword for http APIs which are not hypertext-driven but are very much protocol-specific.
- goto11 5y ago
  It is the style of API's people commonly call REST API's which he suggest should be rebranded to HTTP API's. Because they are not really REST and don't need to be. He is not suggesting rebranding the architectural style known as REST.
  - rualca 5y ago
    > It is kind of API's people commonly call REST API's which he suggest should be rebranded to HTTP API's. First of all, the title of the blog post is literally "should we rebrand REST?" Secondly, these appeals to rebranding REST APIs is already telling of the author's lack of familiarity and insight into the topic. The concept of RPC-over-HTTP is already widely established, as also the age-old stopgap solutions to REST misnomers and incoherences and buzzword abuses which is the Richardson maturity model https://martinfowler.com/articles/richardsonMaturityModel.html https://martinfowler.com/articles/richardsonMaturityModel.ht... I mean, look at the date that article was posted. 2010. It's over a decade old. This debate is not new, and is already solved. We know what REST is. We know that HATEOAS is a key part, and one that no one implements. We know that there are plenty of ignorant folks starving to put buzzwords on their CV. We know that most people end up using resource-driven RPC-over-HTTP with no hypermedia or discoverability. Just because a blogger failed to do his homework and happened to feel emboldened to coin new buzzwords that doesn't mean he's making any point at all or providing any value.
    - unscaled 5y ago
      The blog post explicitly mentions the Richardson Maturity model. He also says that even systems or designs are consciously trying to acheive Level 3 in the Richardson model (HATEOAS) such as JSON-LD with Hydra or JSON:API are still not RESTful in practice. This seems to be the main point of the article, but it is quite hidden. The idea of an app that can display and manipulate data on a distributed network of servers using a well-defined set of JSON-based content types is very interesting. But this is not what the vast majority of currently existing "REST APIs" (even those who are using a more hypermedia-oriented format like JSON:API or JSON-LD) are trying to do. I personally think it is too late to rebrand "REST". Like a lot of confusing names (NoSQL, Serverless, "Cloud", "JavaScript"), it is here to stay. But the main point the author is trying to make is that there are true Hypermedia API clients (which are virtually non-existent in the wild) and HTTP API with various concepts borrowed from the REST model (but are not fully RESTful themselves).
tuxie_ 5y ago
The author suggests that "there's just far too much confusion about what REST means to rescue it" and suggests differentiating APIs in 2 other categories instead, but in my opinion this not only introduces more confusion, but even there doesn't seem to be any constrain that would prevent the same confusion from arising again. There's no library to enforce a certain standard. It's just another set of well-intentioned guidelines. In a few years we would be reading "should we rebrand Hypermedia APIs?" kind of blog posts.
- slver 5y ago
  > in my opinion this not only introduces more confusion I don't think that's possible. I've officially banned the word "REST" from being used in technical discussions. Using that word is not just useless, it's harmful. Note that this is not an issue with the original paper, but everything that happened after it.
  - goto11 5y ago
    The problem is not REST per se, the problem is people thinking a machine-to-machine API "should" conform to REST. I have not seen a coherent argument for why HATEOAS should be a useful property for API's beside "REST says so". That said, we should not throw the baby out with the bathwater. Some REST principles like statelessness are good design for API's also.
    - pa7x1 5y ago
      100% agree, HATEOAS is rather useless for machine-to-machine. And it shouldn't come as a surprise that most APIs decide to not commit to this design constraint. I prefer to think of real-world APIs as coming in varying degees of RESTfulness depending on the design constraints they have chosen to conform to. Good engineering is about making judicious analysis of the trade-offs involved, if HATEOAS doesn't bring you anything dropping it is the right thing to do.
      - Joker_vD 5y ago
codetrotter 5y ago
> REST is just the coolest thing in web service API design right now, isn't it? Is it? I still make my APIs REST-like, but I think in terms of “coolness”, GraphQL is more appealing to people isn’t it? Personally I reason that in my APIs GraphQL would be extra complexity for no benefit in my specific use-cases so far. And REST-like serves me well. But for me I choose this way because of ergonomics and because it allows me to implement the things I do with about the least amount of complexity. Coolness doesn’t play a part anymore. But if it did I would surely think GraphQL would be more cool.
- jayd16 5y ago
  >GraphQL is more appealing to people isn’t it? Its new but it has no where close to the usage of REST, I would imagine.
quantified 5y ago
I wholeheartedly agree with the majority of this. In my experience “REST” has been like a religion in which hardly anyone either read the founding text or bothered to interpret very much of it. Fielding’s thesis does not require all of what adherents have claimed it does. An API does not a priori need to adhere to any sect of “REST”, though for many use cases it will benefit. For example, a machine-to-machine API might well have verb URLs to execute something. That’s verboten, a sin but not an excommunicating taboo, in “REST”. The torch carriers can get very specific about a great many aspects, too. I find it refreshing when someone makes good use of HTTP in a way that REST would forbid. For example, if memory serves, Elasticsearch’s search API uses a GET verb, appropriate for retrieving, with a request body to provide information that would be super awkward in the URI. This API is not intended for UI usage, so why not do this? User interfaces can very much benefit from strategic adoption of application state transitions modeled via hypermedia-style links, that’s entirely different. How likely is it, however, that even if Roy wrote an article in a major publication and gave talks at conferences about what’s not really REST, the community would change its use of “RESTful”?
- h0h0h0h0111 5y ago
  >How likely is it, however, that even if Roy wrote an article in a major publication and gave talks at conferences about what’s not really REST, the community would change its use of “RESTful”? Ha if agile is anything to go by, people on LinkedIn will be describing their recruiting process or marketing strategy or breakfast as RESTful
  - bryanrasmussen 5y ago
    our recruiting process is based on a set of idempotent responses, for example if you send in a cover letter for a full stack position we immediately respond with an email asking you to confirm that you are a rockstar ninja.
- fatnoah 5y ago
  >I find it refreshing when someone makes good use of HTTP in a way that REST would forbid I've written many "REST" interfaces in my time and definitely tried to make the "right" choice vs. the dogmatically correct one when it made sense. I still have a copy of API documentation I wrote "with apologies to Roy Fielding."
DonHopkins 5y ago
How about simply using "BEST Practices"? The trademark "YOU'VE TRIED THE REST, NOW TRY THE BEST" is officially abandoned, so that's available. https://trademark.trademarkia.com/youve-tried-the-rest-now-try-the-best-85894317.html https://trademark.trademarkia.com/youve-tried-the-rest-now-t...
- rualca 5y ago
  > How about simply using "BEST Practices"? REST is already an architecture style, nothing more than an a set of guidelines to design interfaces in order to ensure you get specific qualities and operational advantages. These articles with bold statements regarding the need to change buzzwords already miss the whole point to begin with, and provide absolutely nothing of value.
  - DonHopkins 5y ago
    That's kind of my point. "Use BEST Practices" is nothing more than a set of guidelines, a bold statement to ignore the buzzwords and just do what is currently understood to work the best with today's technologies, whatever buzzwords those practices are currently called, which change over time. For example: BEST Practices a couple decades ago said to use XML over HTTP, while BEST Practices today say to use JSON over HTTPS. Plus, it makes you think of eating pizza, instead of sleeping! https://www.reddit.com/r/theouterworlds/comments/ek4gh5/pizza_place_in_my_small_town_has_a_slogan_that/ https://www.reddit.com/r/theouterworlds/comments/ek4gh5/pizz...
    - rualca 5y ago
      > That's kind of my point. "Use BEST Practices" is nothing more than a set of guidelines (...) I think you're missing the whole point. REST refers to a specific architecture style which comprises a set of very specific design criteria which are explicitly and very clearly specified in a doctoral dissertation. The term REST is a term that was coined to refer to that very specific set of design criteria once applied as a whole. Not in part, not as a cherry-picked assortment of choices, but as a whole. So no, the term doesn't apply to a loose set of guidelines which some guy decided to use just because. It would be like stating you're using HTTP just because you set up a protocol that does request-response and might have support for annotations passed as.key:value pairs resembling headers, buy at the same time had no verbs.
vfc1 5y ago
I don't think anyone cares, really. It's a well established name, people knows what it means a REST-style API. It's not perfect, but nothing is, it's good enough. Let's not change its name, what would be the benefit of it? It would only cause even more confusion for no good reason.
- incrudible 5y ago
  Nitpickers do care. When they start adding HATEOAS and shoehorning semantics into HTTP verbs to make the API more RESTful, they make everything worse to use. The problem is that REST is a buzzword, so you want to keep the word somehow, but throw out the nonsense.
  - thih9 5y ago
    > Nitpickers do care. When they start adding HATEOAS and shoehorning semantics into HTTP verbs to make the API more RESTful, they make everything worse to use. Sounds like bad work organisation or bad priorities are a factor too. These same people could as well make sure some other spec is followed to the letter; e.g. email validation logic from another HN submission [1]. [1]: https://news.ycombinator.com/item?id=27263141 https://news.ycombinator.com/item?id=27263141
- slver 5y ago
  > people knows what it means a REST-style API Oh they know what it means. They just don't agree about it. It's kinda like politics and sports. Everyone is an expert.
- Gunax 5y ago
  I actually really don't think most people know what it means. Personally, I was on a team of over 10 devs and I am pretty sure none of us knew what REST really meant (including me at the time). The author is practically correct--RESTful is so misunderstood that even large companies label their APIs as RESTful when they aren't.
  - petee 5y ago
sergioisidoro 5y ago
Rebranding misses the point, because most people who claim to provide a REST API are actually providing web API that completely misses many of the rest principles. What we need to do is retrain everyone to use the more general term "Web API" and reclaim the term "rest" for architecture and design decision discussions.
- goto11 5y ago
  I think HTTP API is fine. "Web" implies some form of hypertext or hypermedia, but this is not required in a API.
  - zozbot234 5y ago
    "Web" standards include the Semantic-Web/Linked-Data stack for non-hypertext data, which is highly reliant on REST-like and HATEOAS principles.
- bklaasen 5y ago
  Yeah, I call these types of APIs "JSON over HTTP". More syllables than "RESTful API", but everyone knows what I'm talking about.
jayd16 5y ago
Can we just stop jerking off about what is and isn't REST and instead just focus on the pros and cons of any given API? RESTfulness is a useful pattern with some clear advantages. Its not a commandment.
Gunax 5y ago
The term really is a bit too academic to understand for a lot of people who are unfamiliar with API design, but comes down to fairly simple concepts when explained in plain language. I compare it to how monads have an ivory tower definition (the famous 'A monad is just a monoid in the category of endofunctors!') for mathematicians, but can be explained in practical terms much more helpfully, even if that loses some theory. Years ago I edited the Wikipedia page--it has always been thorny. The trouble is that the definition of REST is so abstract as to be completely meaningless to the average person reading the article. If you hate using your finite lifespan on something useful, read the talk page. You will find this same edit war playing out over 10+ years between the theorists ('a style of client-server stateless API design where resources undergo state transitions') and the realists who (mis-) define it as a HTTP api. Even though the theorists are correct, I think it's important to recognize that Wikipedia is going to be the first source of for literally millions of people. It would be a tragedy to not acknowledge that.
nodex-alex 5y ago
Perhaps what everyone considers is the norm is actually the norm. If the whole world decided a Rose was called a Dog then a Rose would be known as a Dog!
shp0ngle 5y ago
People really misunderstand REST, at least as in the original thesis. The original thesis was for the web. It was not meant for microservice JSON APIs. And the web is REST. HTTP, built for web, is REST. The REST principles are integrated in HTTP protocol itself, for I think two decades now. The arguments "is this API RESTful" are nonsense. ...but yeah the article says the same, now that I actually read it. ...now, let's discuss what "agile" means. Or, maybe not.
- wingi 5y ago
  Yes, REST is simple a sub-set of HTTP. Nothing more.
  - zozbot234 5y ago
    The article says otherwise, though. Using HTTP verbs properly is not sufficient for an API to be fully REST-based.
- ncphil 5y ago
  No. Just no. It was the "branding" of Agile by consulting companies and publishers as a product they could sell is what got us into the sh*t show we're now in. Same has happened with REST and everything else the marketers touch. No. The _last_ thing we need is another vacuous rebranding. Unsurprisingly, most of the commentors here seem to get that, and are already calling out the b.s. when given the chance.
dw-im-here 5y ago
We should rebrand REST to Rest to emphasize that the original meaning is lost and that we just use it as a shorthand for a http like API. When it comes to web it's best to set our standards as low as possible because being right doesn't seem to have any advantage over being wrong wrt adoption.
francislavoie 5y ago
I've given up on REST and I build all my new APIs with JSON-RPC. https://www.jsonrpc.org/specification https://www.jsonrpc.org/specification Super simple. I'm not a fan of the complexity things like gRPC introduce to most languages (the PHP tooling is horrible for example), and I really don't like the limitations of HTTP verbs and the box that trying to confirm to CRUD puts you in.
- guggle 5y ago
  I second this (although I'd just stick with JSON-RPC 1.0). REST has its uses case, but alas it's now so ubiquitous that developers don't even think about wether they should or should not use it. For machine to machine communication between heterogenous systems, the simplicity of JSON-RPC means one can implement a client easily in any language. Also creating method stubs is trivial. The payload is still human-readable should you use it from the browser and it's not prone to debates and interpretations around the meaning of HTTP verbs. All you have to know is what method you want to call and with what arguments... something that is natural to all developers, while they almost always get the endpoints/resources/verbs thing wrong.
- lloydatkinson 5y ago
  > Updated: 2013-01-04 I'll pass...
  - francislavoie 5y ago
    I don't see how that's a problem. There hasn't needed to be any updates to the spec. It's simple and it works.
Zababa 5y ago
The point about the World Wide Web being an implementation of REST was really interesting, and now that I think about it web pages are one of the few things that usually respect HATEOAS. I'm reminded of one article by the author of intercooler.js and htmx, "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...), that made the same point but that I didn't understand fully when I read it.
einrealist 5y ago
Well-written article. Its always fun to inspire coworkers/peers to actually read Fielding's dissertation and then have a proper discussion about what REST actually is/means. There are those who get it and are eager to think about the architectural side of the networked apps they work on/with. And then there are those who just want to code / get things done. I can't be angry about the latter ones. But thinking more about architectural implications would bring us forward in the long term. Whenever I use or write an OpenAPI/Swagger definition, my heart breaks. At least it gets work done. But that's also the reason why I personally still prefer good old server-side rendered HTML with progressive enhancement. There is so much overhead involved in defining some arbitrary HTTP API and then have a UI in some overly complex way. HTML is such a powerful tool to drive the client (the Browser).
Communitivity 5y ago
"there's just far too much confusion about what REST means to rescue it" No, there is no confusing. REST is exactly what's in Roy Fielding's thesis. Anything as is derived from REST, often with dismal ends. RESTful, RESTlike, RESTish are weasel words designed to say something along the lines of 'It's REST, but with these additions', or 'It's REST, but with these constraints loosened', or a mix of both. I was there at the beginning of SOA in 2004 and SOA then was an amazingly useful concept that worked well. The term SOA was hijacked to mean so many things, often by consultants pitching their version of SOA enablement or training, and at a rapid pace. By 2009 the meaning of SOA was so buzzwordy and clouded that people were trying to invent new terms to refer to the original concept. If someone wants to create a new thing, create a new thing and give attribution to the shoulders you stand on (i.e., ABC is based on REST but is different in these ways..1,2,3).
- tomnipotent 5y ago
  SOA was overloaded even in 2004, when IBM was promoting it heavily. In 2021, it so inclusive that even microservices fall under its purview. > often by consultants pitching You do realize the term originated by consultants, like many other terms used today (DDD, Gang of Four, Agile, anything from Fowler/Martin etc.). Consultants may not always be the best at implementing things, but I've always found that they do a great job of giving names and marketing repeatable business/software processes.
  - Communitivity 5y ago
    You're probably right. The Thomas Erl book came out in 2004, so it was popular at least a year before that. Btw, I am a consultant. As for implementing things - there are consultants that track toward the marketing/image side of the spectrum and there are those that track toward the shipping/substance side of the spectrum, as in all things. On naming you are spot on. Being good at naming things is almost a job requirement. I've been at larger companies where there were multiple training sessions on how to name things for marketing, and when to hire outside consultants to come up with the names. I was on one project where tech leadership was outspoken and stepped on some toes. They respun the projects concept slightly and changed the name to sidestep the animosity.
bborud 5y ago
HTTP API is awkward to pronounce. Why not call it Web API?
- nicaragua 5y ago
  At least "HTTP API" has some sort of context. Web APIs can be anything from data transmission, media capturing, rendering, cryptography, etc.
  - bborud 5y ago
    Fair points, but "HTTP API" still isn't a good name.
    - nicaragua 5y ago
      I agree with that, hence the quotations.
fmakunbound 5y ago
No, it does not deserve a rebrand. It owns the ecosystem of shit that it brought about over the last two decades. I cannot tell you how many meetings I've sat through where engineers have wasted time on discussing the RESTiness of a given "API" call, or which verb makes the most sense. Anyway, we're only a couple of years of group think away from adopting something like JSON-RPC and then it's welcome back to 1999 for all.
- geodel 5y ago
  Excellent point. It is like I said for Facebook is great for me in sense all folks who I have no interest in contacting are gathered at one place. So now I can avoid all in one simple way. > I cannot tell you how many meetings I've sat through where engineers have wasted time... We have similar REST experts who are making everyone else's life hell.
  - deleted 5y ago
    [deleted]
  - Udik 5y ago
    Oh yes, the best were those who seriously claimed, in my company, that actual endpoints should have been random UUIDs. Because, you know, you must get there only through "discoverability" and hypermedia links.
- kag0 5y ago
  > which verb makes the most sense I think that's a valid discussion. Each method has specific semantics in the HTTP spec, and consumers of an API (both automated and human) will expect you to follow them. For example, I expect to be able to retry a PUT request without much concern. But if I'm not able to do that then that's a problem that would have been worth a discussion.
  - mmcdermott 5y ago
    I think the problem with REST is that these kinds of semantics discussions are helpful _if_ you go all in. Frankly, I've never seen anything more than toy apps that went all in. Most of the world wants JSON-RPC and is bending towards REST to be "correct." I suspect that giving in to RPC would be cleaner overall. Until we build proper RPC composition (via lightweight monads, I'm sure) and let that sweep the world.
fooyc 5y ago
REST is largely over-hyped as an API design. REST fundamentally represents data transfers. No business can be modeled purely as data transfers. CRUD API would be a good name.
- beders 5y ago
  It is not overhyped at all. It is misunderstood. If you pick an API stack, consider your users. If you build an API for general consumption that you want to gradually evolve and that should remain valid years from now, a RESTful API with HATEOS is a great choice. If you need to drive a UI from your API and you control that UI, use something that makes you more productive and can be easily changed on both ends quickly - without regards to backward compatibility. Not sure I understand: > No business can be modeled purely as data transfers. Most businesses can, unless you have a very different definition of what a data transfer is.
  - fooyc 5y ago
    Most business can in a convoluted way. But should you they? Take HN as an example. People can upvote comments. Should you represent the action of upvoting as a resource creation, in a REST way ? Or as an action ? Take Amazon, how do you represent the action of putting a cart item aside ? The action of paying ? The action of changing which card is the default one ?
    - sseagull 5y ago
      Thanks for putting it succinctly. I was going over some REST design principles and the "no verbs in the URL" thing is just really awkward and not intuitive (and something being non-intuitive leads to complexity in my opinion). As in your examples, people think in terms of data (noun) and what they want to do with it (verb). Cramming everything into 4-ish verbs makes it awkward. The solution given for this is usually to put the action in the body. But that feels like working around a limitation that doesn't even have to be there.
    - conradludgate 5y ago
      > People can upvote comments. Should you represent the action of upvoting as a resource creation, in a REST way ? Maybe yes. Likes are a relationship between a User and a Post/Comment. In a standard normalised relational db model, they would have their own table. So `PUT /like` would add a Like to that table
scrumper 5y ago
This is interesting, and I broadly agree with Kieran's complaints about the quasi-REST-lite that passes for web APIs today. Sadly there's not much tooling or guidance around to try and encourage people to do REST properly. It's really not done well at migrating out of academia, as the author points out, and that's starting to look like a missed opportunity for industry. Other comments here seem to tacitly accept that (lots of "Oh well... is what it is.") Everyone's learned to operate within the status quo, but it's quite costly for API consumers to deal with a range of idiosyncratic APIs (and it's bad for providers too: trying to produce something ergonomic and consumable takes significant effort). Hypermedia would make a lot of that cost go away by making APIs inherently discoverable and eliminating all those unique client libraries and boilerplate. (Plug follows) To try and address that and, in the process, nudge the world towards building and using true hypermedia APIs, I and a couple friends started building https://intertron.dev https://intertron.dev - a mechanism to turn any web API into a proper, hypermedia REST API. Contact us on that page if this is a topic of interest, we'd love to talk. We can let you have a play with the pre-launch version too.
- jimmaswell 5y ago
  I access a url with some parameters, I get a JSON object out, and it's documented what side effects or whatever happen. Why do we need more structure than that? I don't really see the need.
- Kinrany 5y ago
  Can you generate a client library for that?
0xbadcafebee 5y ago
> Client applications would not need to be hard-coded with any domain-specific knowledge of the server-side APIs they interact with. Instead, they would discover all the available resources and operations dynamically, at runtime. A client application developed for one hypermedia API could be easily forked and modified for another hypermedia-driven web service. And "smart clients", which are capable of consuming any hypermedia API with a common grammar, could become a reality. This is WSDL and WADL, basically, except there's no common grammar to render a usable interface. The only real thing like what is described is a browser. If you want a universal interface, you make a web app, and the browser is the universal UI. Otherwise you just make a crappy console app and a crappy custom protocol using a HTTP API (or if you hate compatibility, simplicity and convenience: gRPC). To answer the poster's question, no, we're not going to rebrand REST. There are tons of improperly used terms that have been around for ages, they do not get rebranded. You just have to make a new thing and give it a new name and hope that it too isn't misused. ("DevOps" is the most glaring example to me, but also add "hacker", "crypto", "web", "cloud", "container", etc)
crubier 5y ago
I’ve been in GraphQL land for 4-5 years now, and all these discussions about restfulness, Http and other details make me cringe. It feels like watching apes fighting about whether the cylinder goes in the triangle or star-shaped hole. It does not fit! Realize this and move on! Unless your company is only about CRUD (with no JOINs), the Rest model is severely limited or mismatched to your business domain. Just use GraphQL already. It’s actually simple, I promise! Self documenting, introspectable, supports so much code generation and validation tools, etc... I know I’ll get downvoted for saying this, the HN crowd thinks « GraphQL = complicated » for some reason.
- jpdb 5y ago
  I've liked GraphQL the few times I've used it, but I think the standard way of doing pagination with `node`s and `edge`s makes me feel less like I'm working with my data and more some odd abstraction. I think if I used GraphQL more I could get over it, but that aspect always makes me wish for just a bit more.
  - crubier 5y ago
    What you are talking about is the Relay specification, not GraphQL. Relay is completely optional and only a way to optimize performance of client side stuff. Here is how you deal with lists in normal GraphQL: type Query { projects(first: Int): [Project!]! } type Project { id: Int name: String }
- andrewmcwatters 5y ago
  GraphQL is inherently more complicated. It's one more step at a minimum, and more honestly two or three more steps. I can build an endpoint and point it straight to a parameterized SQL query. With GraphQL, I build an endpoint, and point it straight to a GraphQL... schema? And then I have to define where that data comes from, and then how to return it... It's just professional negligence to suggest it's not more involved.
  - crubier 5y ago
andrewmcwatters 5y ago
This is all pedantry. I don't think I've ever talked to a developer who cares. All people care about is whether or not you have a sane API to work with over HTTP. It uses appropriate verbs, maybe, and has meaningful endpoints and request and response objects you work with, hopefully. You can make up a new acronym for it like "WNI" or Web Negotiation Interface, but it doesn't change anything that people care about. There are bigger problems in the world. No need to keep redefining dirt. If you spend a considerable amount of time pondering such things, it's probably a sign that you need to be growing somewhere else in life and using those skills to enhance your existing ones. Have tires really changed that much in 200 years?
- alephu5 5y ago
  REST will be rebranded one day because our industry loves renaming old ideas and presenting them as new. I agree with you though, it's pointless.
  - datavirtue 5y ago
    I think we rather realize that the original meaning was misconstrued and then have to use different terminology to describe the original idea because the original terms have been co-opted. It looks like an old idea being presented as new and indeed it is new to many.
- Kinrany 5y ago
  As it is, REST is not standardized enough for automation. It should be possible to generate a client library in any language just from the service's self-description.
  - sitkack 5y ago
    The poetry of writing semantically meaningful urls is gone. We need really detailed descriptions of the interface boundary, who is responsible and how things are encoded, such that one can use any language they wish for either side of the call. This problem has been solved before.
mybrid 5y ago
It has been my experience that most programming terms end up being business or marketing driven if they gain much traction. My pet peeve at one time is API. This term contains the word "interface", meaning external code will interface with your code. However, business calls everything an API and it means a unit of software work from their perspective. Probably the goofiest one is AI. When people say they are using AI it doesn't tell me anything. What is a VM? Python, Perl and other interpreted languages are said to run in a VM. Isn't a container a VM? A container is just host OS VM. I remember when VMWare only had host OS VMs until they came out with the Hypervisor VM, ESXi. Docker is a brand of container and both are VMs. The point is that it is human nature that any word that becomes popularized will take on business and marketing purposes. You just have to roll with it unless one is expressly carrying out technical communication, then clarity of definition does matter.
jslakro 5y ago
Interesting that other post available in the same blog is about... rebranding javascript -_-
datavirtue 5y ago
Reminds me of OOP. "Misrepresentation of the REST architecture has spread so far and wide that "REST" has come to be informally understood as a synonym for "HTTP"." Misrepresentation of OOP has spread so far and wide that "OOP" has come to be informally understood as a synonym for using class based languages.
- shrimpx 5y ago
  This is what happens to every umbrella term that covers a hodge podge of broad ideas and patterns. Nobody knows what OOP is because it’s a bullet list of a dozen concepts that varies with which OOP guru you ask. Similarly, REST is a long list of loose ideas and broad guidance.
pjmlp 5y ago
Yeah, what about JSON-RPC? /s
zmix 5y ago
...and call it RESET?
coldcoldground 5y ago
This gets my vote! I've always felt a little silly to have "REST" included in my resume because too many job descriptions mentioned it as a requirement. Once during an interview, I couldn't resist to challenge the interviewer asking me about "RESTful APIs" that I had built in the past, and I explained pretty much the same thing to him. Thankfully, he was quite open to admit that what most people are doing is not REST.
spentu 5y ago
For years I have called my APIs "HTTP API" as they usually do not follow the abstract definition of the REST. And because I've seen so many APIs being called REST that barely follow any definition of a sane API. The whole term is used by people as synonym for an API by management and by developers who never took closer look of the definition/paper. I think that the situation is bit like in OOP, TDD and many other things that cause flame wars. When something good ideas come up, people tend to be religious about it. Instead of taking good ideas and utilize them for better solutions, we take things to extreme and fight about tiniest things.

123 points by bshanks 5y ago

kuu 5y ago

TLDR: REST != web service APIs

cryptos 5y ago
That is exactly the point! Most people talking about "REST" are just talking about web service APIs or HTTP APIs, because they are not aware of the actual meaning. REST became a shallow term.

rualca 5y ago

It makes absolutely no sense to even suggest that REST should be rebranded "HTTP API" or even "hypermedia API" because REST is neither protocol-specific nor is "hypermedia" the only (or even main) design trait. It's like someone who is entirely unfamiliar with REST feels compelled to make bold statements about traits he doesn't fully grasp.

masklinn 5y ago
> nor is "hypermedia" the only (or even main) design trait. If you take REST as what it’s original author defined, then it absolutely is. Fielding literally has an article saying so: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... > REST APIs must be hypertext-driven If you take REST as what it’s become (a worthless buzzword for HTTP-based APIs) then > REST is neither protocol-specific Is wrong in turn. You can’t deny both. Unless you’ve decided to make it even more worthless and just a synonym for « API » I guess.
- rualca 5y ago
  > REST APIs must be hypertext-driven That's a reference to HATEOAS, but the whole point is that REST refers to an entire collection of design traits, where hypermedia is only one of them, and you cannot have REST if you do not meet other design requirements first, such as resource-driven architecture. Making REST all about HATEOAS is almost as bad as making REST all about hard coded paths to resources. > If you take REST as what it’s become (...) REST didn't became anything. It has always been the same thing. It's specification is set in stone in the doctoral thesis, and complemented with subsequent posts and public statements from the author. This sort of post has nothing to do with REST at all. It has zero to do with technology or design. This is vacuous and baseless buzzword bingo that adds nothing of value and just manifest a fundamental misunderstanding of the subject that is intended to be discussed. We already have RPC-over-HTTP. It's not REST, everyone knows that. That's a very old concept, as is the resistance to implement HATEOAS. There is nothing of value in this. It's just a clear sign that the author jumped to the part where he feels compelled to coin buzzwords by appropriating established and well-defined concepts while skipping the part he gets acquainted with the subject, thus showing a fundamental misunderstanding of the whole topic.
- jayd16 5y ago
  >A REST API should not be dependent on any single communication protocol I think hypertext is wider than HTTP as far as this blog post in concerned.
  - masklinn 5y ago
    > I think hypertext is wider than HTTP as far as this blog post in concerned. Yes? Did you wildly misread my comment? REST is either the original definition, in which it is hypertext-driven and protocol-agnostic, or a worthless buzzword for http APIs which are not hypertext-driven but are very much protocol-specific.
goto11 5y ago
It is the style of API's people commonly call REST API's which he suggest should be rebranded to HTTP API's. Because they are not really REST and don't need to be. He is not suggesting rebranding the architectural style known as REST.
- rualca 5y ago
  > It is kind of API's people commonly call REST API's which he suggest should be rebranded to HTTP API's. First of all, the title of the blog post is literally "should we rebrand REST?" Secondly, these appeals to rebranding REST APIs is already telling of the author's lack of familiarity and insight into the topic. The concept of RPC-over-HTTP is already widely established, as also the age-old stopgap solutions to REST misnomers and incoherences and buzzword abuses which is the Richardson maturity model https://martinfowler.com/articles/richardsonMaturityModel.html https://martinfowler.com/articles/richardsonMaturityModel.ht... I mean, look at the date that article was posted. 2010. It's over a decade old. This debate is not new, and is already solved. We know what REST is. We know that HATEOAS is a key part, and one that no one implements. We know that there are plenty of ignorant folks starving to put buzzwords on their CV. We know that most people end up using resource-driven RPC-over-HTTP with no hypermedia or discoverability. Just because a blogger failed to do his homework and happened to feel emboldened to coin new buzzwords that doesn't mean he's making any point at all or providing any value.
  - unscaled 5y ago
    The blog post explicitly mentions the Richardson Maturity model. He also says that even systems or designs are consciously trying to acheive Level 3 in the Richardson model (HATEOAS) such as JSON-LD with Hydra or JSON:API are still not RESTful in practice. This seems to be the main point of the article, but it is quite hidden. The idea of an app that can display and manipulate data on a distributed network of servers using a well-defined set of JSON-based content types is very interesting. But this is not what the vast majority of currently existing "REST APIs" (even those who are using a more hypermedia-oriented format like JSON:API or JSON-LD) are trying to do. I personally think it is too late to rebrand "REST". Like a lot of confusing names (NoSQL, Serverless, "Cloud", "JavaScript"), it is here to stay. But the main point the author is trying to make is that there are true Hypermedia API clients (which are virtually non-existent in the wild) and HTTP API with various concepts borrowed from the REST model (but are not fully RESTful themselves).

tuxie_ 5y ago

The author suggests that "there's just far too much confusion about what REST means to rescue it" and suggests differentiating APIs in 2 other categories instead, but in my opinion this not only introduces more confusion, but even there doesn't seem to be any constrain that would prevent the same confusion from arising again. There's no library to enforce a certain standard. It's just another set of well-intentioned guidelines. In a few years we would be reading "should we rebrand Hypermedia APIs?" kind of blog posts.

slver 5y ago
> in my opinion this not only introduces more confusion I don't think that's possible. I've officially banned the word "REST" from being used in technical discussions. Using that word is not just useless, it's harmful. Note that this is not an issue with the original paper, but everything that happened after it.
- goto11 5y ago
  The problem is not REST per se, the problem is people thinking a machine-to-machine API "should" conform to REST. I have not seen a coherent argument for why HATEOAS should be a useful property for API's beside "REST says so". That said, we should not throw the baby out with the bathwater. Some REST principles like statelessness are good design for API's also.
  - pa7x1 5y ago
    100% agree, HATEOAS is rather useless for machine-to-machine. And it shouldn't come as a surprise that most APIs decide to not commit to this design constraint. I prefer to think of real-world APIs as coming in varying degees of RESTfulness depending on the design constraints they have chosen to conform to. Good engineering is about making judicious analysis of the trade-offs involved, if HATEOAS doesn't bring you anything dropping it is the right thing to do.
    - Joker_vD 5y ago

codetrotter 5y ago

> REST is just the coolest thing in web service API design right now, isn't it? Is it? I still make my APIs REST-like, but I think in terms of “coolness”, GraphQL is more appealing to people isn’t it? Personally I reason that in my APIs GraphQL would be extra complexity for no benefit in my specific use-cases so far. And REST-like serves me well. But for me I choose this way because of ergonomics and because it allows me to implement the things I do with about the least amount of complexity. Coolness doesn’t play a part anymore. But if it did I would surely think GraphQL would be more cool.

jayd16 5y ago
>GraphQL is more appealing to people isn’t it? Its new but it has no where close to the usage of REST, I would imagine.

quantified 5y ago

I wholeheartedly agree with the majority of this. In my experience “REST” has been like a religion in which hardly anyone either read the founding text or bothered to interpret very much of it. Fielding’s thesis does not require all of what adherents have claimed it does. An API does not a priori need to adhere to any sect of “REST”, though for many use cases it will benefit. For example, a machine-to-machine API might well have verb URLs to execute something. That’s verboten, a sin but not an excommunicating taboo, in “REST”. The torch carriers can get very specific about a great many aspects, too. I find it refreshing when someone makes good use of HTTP in a way that REST would forbid. For example, if memory serves, Elasticsearch’s search API uses a GET verb, appropriate for retrieving, with a request body to provide information that would be super awkward in the URI. This API is not intended for UI usage, so why not do this? User interfaces can very much benefit from strategic adoption of application state transitions modeled via hypermedia-style links, that’s entirely different. How likely is it, however, that even if Roy wrote an article in a major publication and gave talks at conferences about what’s not really REST, the community would change its use of “RESTful”?

h0h0h0h0111 5y ago
>How likely is it, however, that even if Roy wrote an article in a major publication and gave talks at conferences about what’s not really REST, the community would change its use of “RESTful”? Ha if agile is anything to go by, people on LinkedIn will be describing their recruiting process or marketing strategy or breakfast as RESTful
- bryanrasmussen 5y ago
  our recruiting process is based on a set of idempotent responses, for example if you send in a cover letter for a full stack position we immediately respond with an email asking you to confirm that you are a rockstar ninja.
fatnoah 5y ago
>I find it refreshing when someone makes good use of HTTP in a way that REST would forbid I've written many "REST" interfaces in my time and definitely tried to make the "right" choice vs. the dogmatically correct one when it made sense. I still have a copy of API documentation I wrote "with apologies to Roy Fielding."

DonHopkins 5y ago

How about simply using "BEST Practices"? The trademark "YOU'VE TRIED THE REST, NOW TRY THE BEST" is officially abandoned, so that's available. https://trademark.trademarkia.com/youve-tried-the-rest-now-try-the-best-85894317.html https://trademark.trademarkia.com/youve-tried-the-rest-now-t...

rualca 5y ago
> How about simply using "BEST Practices"? REST is already an architecture style, nothing more than an a set of guidelines to design interfaces in order to ensure you get specific qualities and operational advantages. These articles with bold statements regarding the need to change buzzwords already miss the whole point to begin with, and provide absolutely nothing of value.
- DonHopkins 5y ago
  That's kind of my point. "Use BEST Practices" is nothing more than a set of guidelines, a bold statement to ignore the buzzwords and just do what is currently understood to work the best with today's technologies, whatever buzzwords those practices are currently called, which change over time. For example: BEST Practices a couple decades ago said to use XML over HTTP, while BEST Practices today say to use JSON over HTTPS. Plus, it makes you think of eating pizza, instead of sleeping! https://www.reddit.com/r/theouterworlds/comments/ek4gh5/pizza_place_in_my_small_town_has_a_slogan_that/ https://www.reddit.com/r/theouterworlds/comments/ek4gh5/pizz...
  - rualca 5y ago
    > That's kind of my point. "Use BEST Practices" is nothing more than a set of guidelines (...) I think you're missing the whole point. REST refers to a specific architecture style which comprises a set of very specific design criteria which are explicitly and very clearly specified in a doctoral dissertation. The term REST is a term that was coined to refer to that very specific set of design criteria once applied as a whole. Not in part, not as a cherry-picked assortment of choices, but as a whole. So no, the term doesn't apply to a loose set of guidelines which some guy decided to use just because. It would be like stating you're using HTTP just because you set up a protocol that does request-response and might have support for annotations passed as.key:value pairs resembling headers, buy at the same time had no verbs.

vfc1 5y ago

I don't think anyone cares, really. It's a well established name, people knows what it means a REST-style API. It's not perfect, but nothing is, it's good enough. Let's not change its name, what would be the benefit of it? It would only cause even more confusion for no good reason.

incrudible 5y ago
Nitpickers do care. When they start adding HATEOAS and shoehorning semantics into HTTP verbs to make the API more RESTful, they make everything worse to use. The problem is that REST is a buzzword, so you want to keep the word somehow, but throw out the nonsense.
- thih9 5y ago
  > Nitpickers do care. When they start adding HATEOAS and shoehorning semantics into HTTP verbs to make the API more RESTful, they make everything worse to use. Sounds like bad work organisation or bad priorities are a factor too. These same people could as well make sure some other spec is followed to the letter; e.g. email validation logic from another HN submission [1]. [1]: https://news.ycombinator.com/item?id=27263141 https://news.ycombinator.com/item?id=27263141
slver 5y ago
> people knows what it means a REST-style API Oh they know what it means. They just don't agree about it. It's kinda like politics and sports. Everyone is an expert.
Gunax 5y ago
I actually really don't think most people know what it means. Personally, I was on a team of over 10 devs and I am pretty sure none of us knew what REST really meant (including me at the time). The author is practically correct--RESTful is so misunderstood that even large companies label their APIs as RESTful when they aren't.
- petee 5y ago

sergioisidoro 5y ago

Rebranding misses the point, because most people who claim to provide a REST API are actually providing web API that completely misses many of the rest principles. What we need to do is retrain everyone to use the more general term "Web API" and reclaim the term "rest" for architecture and design decision discussions.

goto11 5y ago
I think HTTP API is fine. "Web" implies some form of hypertext or hypermedia, but this is not required in a API.
- zozbot234 5y ago
  "Web" standards include the Semantic-Web/Linked-Data stack for non-hypertext data, which is highly reliant on REST-like and HATEOAS principles.
bklaasen 5y ago
Yeah, I call these types of APIs "JSON over HTTP". More syllables than "RESTful API", but everyone knows what I'm talking about.

jayd16 5y ago

Can we just stop jerking off about what is and isn't REST and instead just focus on the pros and cons of any given API? RESTfulness is a useful pattern with some clear advantages. Its not a commandment.

Gunax 5y ago

The term really is a bit too academic to understand for a lot of people who are unfamiliar with API design, but comes down to fairly simple concepts when explained in plain language. I compare it to how monads have an ivory tower definition (the famous 'A monad is just a monoid in the category of endofunctors!') for mathematicians, but can be explained in practical terms much more helpfully, even if that loses some theory. Years ago I edited the Wikipedia page--it has always been thorny. The trouble is that the definition of REST is so abstract as to be completely meaningless to the average person reading the article. If you hate using your finite lifespan on something useful, read the talk page. You will find this same edit war playing out over 10+ years between the theorists ('a style of client-server stateless API design where resources undergo state transitions') and the realists who (mis-) define it as a HTTP api. Even though the theorists are correct, I think it's important to recognize that Wikipedia is going to be the first source of for literally millions of people. It would be a tragedy to not acknowledge that.

nodex-alex 5y ago

Perhaps what everyone considers is the norm is actually the norm. If the whole world decided a Rose was called a Dog then a Rose would be known as a Dog!

shp0ngle 5y ago

People really misunderstand REST, at least as in the original thesis. The original thesis was for the web. It was not meant for microservice JSON APIs. And the web is REST. HTTP, built for web, is REST. The REST principles are integrated in HTTP protocol itself, for I think two decades now. The arguments "is this API RESTful" are nonsense. ...but yeah the article says the same, now that I actually read it. ...now, let's discuss what "agile" means. Or, maybe not.

wingi 5y ago
Yes, REST is simple a sub-set of HTTP. Nothing more.
- zozbot234 5y ago
  The article says otherwise, though. Using HTTP verbs properly is not sufficient for an API to be fully REST-based.
ncphil 5y ago
No. Just no. It was the "branding" of Agile by consulting companies and publishers as a product they could sell is what got us into the sh*t show we're now in. Same has happened with REST and everything else the marketers touch. No. The _last_ thing we need is another vacuous rebranding. Unsurprisingly, most of the commentors here seem to get that, and are already calling out the b.s. when given the chance.

dw-im-here 5y ago

We should rebrand REST to Rest to emphasize that the original meaning is lost and that we just use it as a shorthand for a http like API. When it comes to web it's best to set our standards as low as possible because being right doesn't seem to have any advantage over being wrong wrt adoption.

francislavoie 5y ago

I've given up on REST and I build all my new APIs with JSON-RPC. https://www.jsonrpc.org/specification https://www.jsonrpc.org/specification Super simple. I'm not a fan of the complexity things like gRPC introduce to most languages (the PHP tooling is horrible for example), and I really don't like the limitations of HTTP verbs and the box that trying to confirm to CRUD puts you in.

guggle 5y ago
I second this (although I'd just stick with JSON-RPC 1.0). REST has its uses case, but alas it's now so ubiquitous that developers don't even think about wether they should or should not use it. For machine to machine communication between heterogenous systems, the simplicity of JSON-RPC means one can implement a client easily in any language. Also creating method stubs is trivial. The payload is still human-readable should you use it from the browser and it's not prone to debates and interpretations around the meaning of HTTP verbs. All you have to know is what method you want to call and with what arguments... something that is natural to all developers, while they almost always get the endpoints/resources/verbs thing wrong.
lloydatkinson 5y ago
> Updated: 2013-01-04 I'll pass...
- francislavoie 5y ago
  I don't see how that's a problem. There hasn't needed to be any updates to the spec. It's simple and it works.

Zababa 5y ago

The point about the World Wide Web being an implementation of REST was really interesting, and now that I think about it web pages are one of the few things that usually respect HATEOAS. I'm reminded of one article by the author of intercooler.js and htmx, "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...), that made the same point but that I didn't understand fully when I read it.

einrealist 5y ago

Well-written article. Its always fun to inspire coworkers/peers to actually read Fielding's dissertation and then have a proper discussion about what REST actually is/means. There are those who get it and are eager to think about the architectural side of the networked apps they work on/with. And then there are those who just want to code / get things done. I can't be angry about the latter ones. But thinking more about architectural implications would bring us forward in the long term. Whenever I use or write an OpenAPI/Swagger definition, my heart breaks. At least it gets work done. But that's also the reason why I personally still prefer good old server-side rendered HTML with progressive enhancement. There is so much overhead involved in defining some arbitrary HTTP API and then have a UI in some overly complex way. HTML is such a powerful tool to drive the client (the Browser).

Communitivity 5y ago

"there's just far too much confusion about what REST means to rescue it" No, there is no confusing. REST is exactly what's in Roy Fielding's thesis. Anything as is derived from REST, often with dismal ends. RESTful, RESTlike, RESTish are weasel words designed to say something along the lines of 'It's REST, but with these additions', or 'It's REST, but with these constraints loosened', or a mix of both. I was there at the beginning of SOA in 2004 and SOA then was an amazingly useful concept that worked well. The term SOA was hijacked to mean so many things, often by consultants pitching their version of SOA enablement or training, and at a rapid pace. By 2009 the meaning of SOA was so buzzwordy and clouded that people were trying to invent new terms to refer to the original concept. If someone wants to create a new thing, create a new thing and give attribution to the shoulders you stand on (i.e., ABC is based on REST but is different in these ways..1,2,3).

tomnipotent 5y ago
SOA was overloaded even in 2004, when IBM was promoting it heavily. In 2021, it so inclusive that even microservices fall under its purview. > often by consultants pitching You do realize the term originated by consultants, like many other terms used today (DDD, Gang of Four, Agile, anything from Fowler/Martin etc.). Consultants may not always be the best at implementing things, but I've always found that they do a great job of giving names and marketing repeatable business/software processes.
- Communitivity 5y ago
  You're probably right. The Thomas Erl book came out in 2004, so it was popular at least a year before that. Btw, I am a consultant. As for implementing things - there are consultants that track toward the marketing/image side of the spectrum and there are those that track toward the shipping/substance side of the spectrum, as in all things. On naming you are spot on. Being good at naming things is almost a job requirement. I've been at larger companies where there were multiple training sessions on how to name things for marketing, and when to hire outside consultants to come up with the names. I was on one project where tech leadership was outspoken and stepped on some toes. They respun the projects concept slightly and changed the name to sidestep the animosity.

bborud 5y ago

HTTP API is awkward to pronounce. Why not call it Web API?

nicaragua 5y ago
At least "HTTP API" has some sort of context. Web APIs can be anything from data transmission, media capturing, rendering, cryptography, etc.
- bborud 5y ago
  Fair points, but "HTTP API" still isn't a good name.
  - nicaragua 5y ago
    I agree with that, hence the quotations.

fmakunbound 5y ago

No, it does not deserve a rebrand. It owns the ecosystem of shit that it brought about over the last two decades. I cannot tell you how many meetings I've sat through where engineers have wasted time on discussing the RESTiness of a given "API" call, or which verb makes the most sense. Anyway, we're only a couple of years of group think away from adopting something like JSON-RPC and then it's welcome back to 1999 for all.

geodel 5y ago
Excellent point. It is like I said for Facebook is great for me in sense all folks who I have no interest in contacting are gathered at one place. So now I can avoid all in one simple way. > I cannot tell you how many meetings I've sat through where engineers have wasted time... We have similar REST experts who are making everyone else's life hell.
- deleted 5y ago
  [deleted]
- Udik 5y ago
  Oh yes, the best were those who seriously claimed, in my company, that actual endpoints should have been random UUIDs. Because, you know, you must get there only through "discoverability" and hypermedia links.
kag0 5y ago
> which verb makes the most sense I think that's a valid discussion. Each method has specific semantics in the HTTP spec, and consumers of an API (both automated and human) will expect you to follow them. For example, I expect to be able to retry a PUT request without much concern. But if I'm not able to do that then that's a problem that would have been worth a discussion.
- mmcdermott 5y ago
  I think the problem with REST is that these kinds of semantics discussions are helpful _if_ you go all in. Frankly, I've never seen anything more than toy apps that went all in. Most of the world wants JSON-RPC and is bending towards REST to be "correct." I suspect that giving in to RPC would be cleaner overall. Until we build proper RPC composition (via lightweight monads, I'm sure) and let that sweep the world.

fooyc 5y ago

REST is largely over-hyped as an API design. REST fundamentally represents data transfers. No business can be modeled purely as data transfers. CRUD API would be a good name.

beders 5y ago
It is not overhyped at all. It is misunderstood. If you pick an API stack, consider your users. If you build an API for general consumption that you want to gradually evolve and that should remain valid years from now, a RESTful API with HATEOS is a great choice. If you need to drive a UI from your API and you control that UI, use something that makes you more productive and can be easily changed on both ends quickly - without regards to backward compatibility. Not sure I understand: > No business can be modeled purely as data transfers. Most businesses can, unless you have a very different definition of what a data transfer is.
- fooyc 5y ago
  Most business can in a convoluted way. But should you they? Take HN as an example. People can upvote comments. Should you represent the action of upvoting as a resource creation, in a REST way ? Or as an action ? Take Amazon, how do you represent the action of putting a cart item aside ? The action of paying ? The action of changing which card is the default one ?
  - sseagull 5y ago
    Thanks for putting it succinctly. I was going over some REST design principles and the "no verbs in the URL" thing is just really awkward and not intuitive (and something being non-intuitive leads to complexity in my opinion). As in your examples, people think in terms of data (noun) and what they want to do with it (verb). Cramming everything into 4-ish verbs makes it awkward. The solution given for this is usually to put the action in the body. But that feels like working around a limitation that doesn't even have to be there.
  - conradludgate 5y ago
    > People can upvote comments. Should you represent the action of upvoting as a resource creation, in a REST way ? Maybe yes. Likes are a relationship between a User and a Post/Comment. In a standard normalised relational db model, they would have their own table. So `PUT /like` would add a Like to that table

scrumper 5y ago

This is interesting, and I broadly agree with Kieran's complaints about the quasi-REST-lite that passes for web APIs today. Sadly there's not much tooling or guidance around to try and encourage people to do REST properly. It's really not done well at migrating out of academia, as the author points out, and that's starting to look like a missed opportunity for industry. Other comments here seem to tacitly accept that (lots of "Oh well... is what it is.") Everyone's learned to operate within the status quo, but it's quite costly for API consumers to deal with a range of idiosyncratic APIs (and it's bad for providers too: trying to produce something ergonomic and consumable takes significant effort). Hypermedia would make a lot of that cost go away by making APIs inherently discoverable and eliminating all those unique client libraries and boilerplate. (Plug follows) To try and address that and, in the process, nudge the world towards building and using true hypermedia APIs, I and a couple friends started building https://intertron.dev https://intertron.dev - a mechanism to turn any web API into a proper, hypermedia REST API. Contact us on that page if this is a topic of interest, we'd love to talk. We can let you have a play with the pre-launch version too.

jimmaswell 5y ago
I access a url with some parameters, I get a JSON object out, and it's documented what side effects or whatever happen. Why do we need more structure than that? I don't really see the need.
Kinrany 5y ago
Can you generate a client library for that?

0xbadcafebee 5y ago

> Client applications would not need to be hard-coded with any domain-specific knowledge of the server-side APIs they interact with. Instead, they would discover all the available resources and operations dynamically, at runtime. A client application developed for one hypermedia API could be easily forked and modified for another hypermedia-driven web service. And "smart clients", which are capable of consuming any hypermedia API with a common grammar, could become a reality. This is WSDL and WADL, basically, except there's no common grammar to render a usable interface. The only real thing like what is described is a browser. If you want a universal interface, you make a web app, and the browser is the universal UI. Otherwise you just make a crappy console app and a crappy custom protocol using a HTTP API (or if you hate compatibility, simplicity and convenience: gRPC). To answer the poster's question, no, we're not going to rebrand REST. There are tons of improperly used terms that have been around for ages, they do not get rebranded. You just have to make a new thing and give it a new name and hope that it too isn't misused. ("DevOps" is the most glaring example to me, but also add "hacker", "crypto", "web", "cloud", "container", etc)

crubier 5y ago

I’ve been in GraphQL land for 4-5 years now, and all these discussions about restfulness, Http and other details make me cringe. It feels like watching apes fighting about whether the cylinder goes in the triangle or star-shaped hole. It does not fit! Realize this and move on! Unless your company is only about CRUD (with no JOINs), the Rest model is severely limited or mismatched to your business domain. Just use GraphQL already. It’s actually simple, I promise! Self documenting, introspectable, supports so much code generation and validation tools, etc... I know I’ll get downvoted for saying this, the HN crowd thinks « GraphQL = complicated » for some reason.

jpdb 5y ago
I've liked GraphQL the few times I've used it, but I think the standard way of doing pagination with `node`s and `edge`s makes me feel less like I'm working with my data and more some odd abstraction. I think if I used GraphQL more I could get over it, but that aspect always makes me wish for just a bit more.
- crubier 5y ago
  What you are talking about is the Relay specification, not GraphQL. Relay is completely optional and only a way to optimize performance of client side stuff. Here is how you deal with lists in normal GraphQL: type Query { projects(first: Int): [Project!]! } type Project { id: Int name: String }
andrewmcwatters 5y ago
GraphQL is inherently more complicated. It's one more step at a minimum, and more honestly two or three more steps. I can build an endpoint and point it straight to a parameterized SQL query. With GraphQL, I build an endpoint, and point it straight to a GraphQL... schema? And then I have to define where that data comes from, and then how to return it... It's just professional negligence to suggest it's not more involved.
- crubier 5y ago

andrewmcwatters 5y ago

This is all pedantry. I don't think I've ever talked to a developer who cares. All people care about is whether or not you have a sane API to work with over HTTP. It uses appropriate verbs, maybe, and has meaningful endpoints and request and response objects you work with, hopefully. You can make up a new acronym for it like "WNI" or Web Negotiation Interface, but it doesn't change anything that people care about. There are bigger problems in the world. No need to keep redefining dirt. If you spend a considerable amount of time pondering such things, it's probably a sign that you need to be growing somewhere else in life and using those skills to enhance your existing ones. Have tires really changed that much in 200 years?

alephu5 5y ago
REST will be rebranded one day because our industry loves renaming old ideas and presenting them as new. I agree with you though, it's pointless.
- datavirtue 5y ago
  I think we rather realize that the original meaning was misconstrued and then have to use different terminology to describe the original idea because the original terms have been co-opted. It looks like an old idea being presented as new and indeed it is new to many.
Kinrany 5y ago
As it is, REST is not standardized enough for automation. It should be possible to generate a client library in any language just from the service's self-description.
- sitkack 5y ago
  The poetry of writing semantically meaningful urls is gone. We need really detailed descriptions of the interface boundary, who is responsible and how things are encoded, such that one can use any language they wish for either side of the call. This problem has been solved before.

mybrid 5y ago

It has been my experience that most programming terms end up being business or marketing driven if they gain much traction. My pet peeve at one time is API. This term contains the word "interface", meaning external code will interface with your code. However, business calls everything an API and it means a unit of software work from their perspective. Probably the goofiest one is AI. When people say they are using AI it doesn't tell me anything. What is a VM? Python, Perl and other interpreted languages are said to run in a VM. Isn't a container a VM? A container is just host OS VM. I remember when VMWare only had host OS VMs until they came out with the Hypervisor VM, ESXi. Docker is a brand of container and both are VMs. The point is that it is human nature that any word that becomes popularized will take on business and marketing purposes. You just have to roll with it unless one is expressly carrying out technical communication, then clarity of definition does matter.

jslakro 5y ago

Interesting that other post available in the same blog is about... rebranding javascript -_-

datavirtue 5y ago

Reminds me of OOP. "Misrepresentation of the REST architecture has spread so far and wide that "REST" has come to be informally understood as a synonym for "HTTP"." Misrepresentation of OOP has spread so far and wide that "OOP" has come to be informally understood as a synonym for using class based languages.

shrimpx 5y ago
This is what happens to every umbrella term that covers a hodge podge of broad ideas and patterns. Nobody knows what OOP is because it’s a bullet list of a dozen concepts that varies with which OOP guru you ask. Similarly, REST is a long list of loose ideas and broad guidance.

pjmlp 5y ago

Yeah, what about JSON-RPC? /s

zmix 5y ago

...and call it RESET?

coldcoldground 5y ago

This gets my vote! I've always felt a little silly to have "REST" included in my resume because too many job descriptions mentioned it as a requirement. Once during an interview, I couldn't resist to challenge the interviewer asking me about "RESTful APIs" that I had built in the past, and I explained pretty much the same thing to him. Thankfully, he was quite open to admit that what most people are doing is not REST.

spentu 5y ago

For years I have called my APIs "HTTP API" as they usually do not follow the abstract definition of the REST. And because I've seen so many APIs being called REST that barely follow any definition of a sane API. The whole term is used by people as synonym for an API by management and by developers who never took closer look of the definition/paper. I think that the situation is bit like in OOP, TDD and many other things that cause flame wars. When something good ideas come up, people tend to be religious about it. Instead of taking good ideas and utilize them for better solutions, we take things to extreme and fight about tiniest things.