Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should we rebrand REST?

kieranpotts.com

Post reply on HN
Print view View original

81–90 of 154 posts

Re: Should we rebrand REST?

#81

Post by dragonwriter »

PeterisP wrote: post #80
Joker_vD wrote: post #50

Earlier quoted context omitted.

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 signifi…

> 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.

If they have “all the info they need”, they have the identity of Y, which in a system designed around REST is the URL, and if Y is a resource, then its URL is the URL for actions on it, and the type of thing it is will tell you what method to use and (where one is applicable) resource to send to accomplish the action.

HATEOAS is more than just shipping URLs.

Re: Should we rebrand REST?

#82

Post by beders »

fooyc wrote: post #71

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.

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.

Re: Should we rebrand REST?

#83

Post by Communitivity »

tomnipotent wrote: post #69
Communitivity wrote: post #58

"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…

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 g…

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.

Re: Should we rebrand REST?

#84

Post by kag0 »

fmakunbound wrote: post #68

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…

> 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.

Re: Should we rebrand REST?

#85

Post by fooyc »

beders wrote: post #82
fooyc wrote: post #71

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.

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…

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 ?

Re: Should we rebrand REST?

#86

Post by sseagull »

fooyc wrote: post #85
beders wrote: post #82

Earlier quoted context omitted.

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…

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 ?

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.

Re: Should we rebrand REST?

#87

Post by ajuc »

mixmastamyk wrote: post #72
bewo001 wrote: post #60

Earlier quoted context omitted.

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.

JSON API would be my preferred name.

Re: Should we rebrand REST?

#88

Post by [deleted] »

geodel wrote: post #70
fmakunbound wrote: post #68

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…

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]

Re: Should we rebrand REST?

#89

Post by shashurup »

fmakunbound wrote: post #68

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…

And then another couple of hours wasted discussing encoding some complex query into url parameters. On the other hand it was a good lesson to avoid such discussions in the future using any feasible excuse.

Re: Should we rebrand REST?

#90

Post by Joker_vD »

aaron-santos wrote: post #64
goto11 wrote: post #43

Earlier 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…

And another take on why clients being able to manually craft URLs is bad design: [0]. But prohibitting clients from manually constructing URLs really is not that hard: [1].

[1] https://blog.ploeh.dk/2013/05/01/rest-lesson-learned-avoid-h...

[2] https://blog.ploeh.dk/2020/10/26/fit-urls/

Post reply on HN