Should we rebrand REST?
kieranpotts.com
Should we rebrand REST?
1–10 of 154 posts
Re: Should we rebrand REST?
#2TLDR: REST != web service APIs
Re: Should we rebrand REST?
#3It 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.
Re: Should we rebrand REST?
#4The 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.
Re: Should we rebrand REST?
#5> 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.
Re: Should we rebrand REST?
#6It 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 turn.
You can’t deny both. Unless you’ve decided to make it even more worthless and just a synonym for « API » I guess.
Re: Should we rebrand REST?
#7> 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 allow…
>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.
Re: Should we rebrand REST?
#8I 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”?
Re: Should we rebrand REST?
#9How 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...
Re: Should we rebrand REST?
#10I 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.