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.
Should we rebrand REST?
71–80 of 154 posts
Re: Should we rebrand REST?
#72Earlier quoted context omitted.
I think their point is that REST means nothing beyond “uses HTTP verbs” these days. Most companies/teams can’t even agree on the differences between POST, PUT and PATCH; let alone status codes, payload structure, authentication, etc. So using the term REST will mean something different to every person using it. Similar to how a Ruby, PHP and Python engineer will envision a different architecture if you tell them to b…
They call REST anything that uses JSON over HTTP nowadays. What I don't get, when they don't know or don't want to do REST, why they are not just calling their API JSON/HTTP?
Say the two phrases out loud and the reason becomes obvious. The second doesn’t exactly roll off the tongue.
Re: Should we rebrand REST?
#73The 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…
> 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.
> I've officially banned the word "REST" from being used in technical discussions.
So if I want to refer to the architecture of that name described in Fielding’s Architectural Styles and the Design of Network-based Software Architectures, what is the approved circumlocution?
Re: Should we rebrand REST?
#74I 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.
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.
I concur most don't know what it means. Years ago I started reading around trying to understand it, and all I found was that the ones who supposedly did understand, really couldn't explain it clearly; and they all had different definitions.
Reminds me of "if you can't explain it simply, you don't understand it well enough"
Re: Should we rebrand REST?
#75Earlier quoted context omitted.
What is the problem with hard-coded URLs? It is certainly simpler than having to extract the URLs from some other request. If they don't change (and they shouldn't!) I don't see the problem.
Harded-coded URLs represent a larger API surface area. Hypermedia-driven APIs eg: HATEOAS permit the server to view URLs as an implementation detail. Some people and some problems benefit from APIs with large surface area. Some people and problems benefit from APIs with small surface area. I tend to like APIs with small surface areas because it means I don't have to drag along outdated endpoints across minor versions…
Even if the client fetches the URL dynamically, nothing about the semantics of that URL parameters or results can change or the client will break, you can only add extra optional things that the old clients will ignore. All those URLs still very much are part of the API surface area even if they're not hardcoded - their functionality still needs to have out-of-bounds documentation (contrary to the HATEOAS assumptions - "self-descriptive messages" IMHO can work only for syntax but are an unrealistic goal as far as semantics is concerned) and fixed behavior to match that documentation, in all realistic cases the client can't properly interpret the data without programmer intervention if the model changes.
So this gives you only the freedom to change the URL naming scheme, but if you want to change the functionality in any way that's not 100% compatible, you still have to drag along outdated endpoints with the old functionality or you'll break clients.
But this goes so much in contrast to your comment that it seems that I'm probably misunderstanding you - can you give an illustrative example on how exactly does this allow you to combine or split endpoints without affecting client software that sends/takes data from those endpoints and does some action (business logic) based on that data?
Re: Should we rebrand REST?
#76Earlier quoted context omitted.
> 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.
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.
> I have not seen a coherent argument for why HATEOAS should be a useful property for API's beside "REST says so".
Loose coupling and extensibility, the same reason that its used on the web, which is quite critically a machine-to-machine protocol (while obviously humans consume it via user-agents, automatic crawling and othee machine-to-machine processing is key to the success of the web) and HATEOAS is key to why it works.
Re: Should we rebrand REST?
#77This 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 - 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.
Re: Should we rebrand REST?
#78This 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…
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.
Re: Should we rebrand REST?
#79Earlier quoted context omitted.
I disagree. Even if an API is effectively used by a machine, the root cause either is human interaction or it makes sense to also allow human interaction (e.g. for testing, troubleshooting, interactive documentation). HATEOAS can help to define formats that solve both problems.
You can define formats without HATEOAS.
Obviously, since defining formats and driving logic through defined and identified-in-band formats is an element but not the whole of HATEOAS. OTOH, applications using pseudo-REST without HATEOAS typically hardcode both URLs and formats rather than relying on in-band identification of both.
Re: Should we rebrand REST?
#80Earlier quoted context omitted.
What is the problem with hard-coded URLs? It is certainly simpler than having to extract the URLs from some other request. If they don't change (and they shouldn't!) I don't see the problem.
Well the problem is exactly that they do change sometimes. And having only one hard-coded URL is easier than having twelve of those. > It is certainly simpler than having to extract the URLs from some other request. It's not extracted from other request, it's extracted from the response to the original request, and using a field from the local struct is not harder than using a global constant.
The practical problem I have seen with systems (mis?)designed like this is a scenario when the client needs to do action X on resource Y attached to thingy Z - and they already have all the required info to do that action - then they still need to do a request on Z to get the URL for Y and do a request on Y to get the url for action X, which adds extra requests and latency for no good reason. Like, there's no significant difference if there is some original request that has been made, but often that "original" request is otherwise unnecessary and only gets made to enable that extra layer of indirection.