11–20 of 154 posts
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.
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.
> 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-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 tur…
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.
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.
> 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-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 tur…
I think hypertext is wider than HTTP as far as this blog post in concerned.
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-t...
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.
RESTfulness is a useful pattern with some clear advantages. Its not a commandment.
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…
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.
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 mig…
Ha if agile is anything to go by, people on LinkedIn will be describing their recruiting process or marketing strategy or breakfast as RESTful
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.
The problem is that REST is a buzzword, so you want to keep the word somehow, but throw out the nonsense.
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.
Oh they know what it means. They just don't agree about it.
It's kinda like politics and sports. Everyone is an expert.
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.