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

61–70 of 154 posts

Re: Should we rebrand REST?

#61

Post by slver »

einrealist wrote: post #57
pa7x1 wrote: post #37

Earlier quoted context omitted.

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

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.

Re: Should we rebrand REST?

#62

Post by slver »

goto11 wrote: post #54
Joker_vD wrote: post #52

Earlier quoted context omitted.

> Well they shouldn't! If you treat them as public interface, they shouldn't, yes. But if you treat them as internal implementation details, they absolutely could. One can also think about it as static vs dynamic dispatch: you make an initial request, you get a vtable of "method name -> method pointer" as a part of response. Or you can hardcode the method pointers and make it the remote server's job to properly chose…

But what is the point? Why introduce an extra layer of complexity to mitigate changing URL's, something which has no purpose in the first place?

Bingo

Re: Should we rebrand REST?

#63

Post by fatnoah »

quantified wrote: post #8

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…

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

Re: Should we rebrand REST?

#64

Post by aaron-santos »

goto11 wrote: post #43
Joker_vD wrote: post #42

Earlier quoted context omitted.

HATEOAS is somewhat useful even in machine-to-machine: hard-coded URLs in clients are kind of a PITA to support.

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 because the org doesn't want to v2 anything. URLs as an implementation detail makes backwards compatibility much easier. So many times it's been useful to combine or split endpoints as the business needs change without affecting clients.

The worst part about using HATEOAS for me has been clients who are used to constructing URLs continue to do so and create a ticket where the obvious first question is "Are you constructing that URL?"

Re: Should we rebrand REST?

#66

Post by hangonhn »

pa7x1 wrote: post #37
goto11 wrote: post #21

Earlier quoted context omitted.

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.

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

HATEOAS was a little more useful when the commonly used media was XML rather than JSON. XML has XPath, which I was able to use to find the URLs for the different actions I want to perform, should they ever change. In practice, however, those URLs never changed or were constructed in a very predictable way.

Re: Should we rebrand REST?

#67

Post by ncphil »

shp0ngle wrote: post #32

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

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.

Re: Should we rebrand REST?

#68

Post by fmakunbound »

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.

Re: Should we rebrand REST?

#69

Post by tomnipotent »

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 great job of giving names and marketing repeatable business/software processes.

Re: Should we rebrand REST?

#70

Post by geodel »

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.

Post reply on HN