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

How did REST come to mean the opposite of REST?

htmx.org

Post reply on HN
Print view View original

221–230 of 393 posts

Re: How did REST come to mean the opposite of REST?

#221

Post by peeters »

Joeri wrote: post #7

The client knows nothing about the API end points associated with this data, except via URLs and hypermedia controls (links and forms) discoverable within the HTML itself. If the state of the resource changes such that the allowable actions available on that resource change (for example, if the account goes into overdraft) then the HTML response would change to show the new set of actions available. If the client kno…

This is right on the money in identifying the continual battle with using a hypermedia API for system-to-system communication. There comes a time where you realize that what you're building is great for discoverability, but not for instructing a computer to do something on your behalf.

That said, the situation isn't entirely dire. With some standard linking conventions (e.g RFC 8288 [1]), you can largely make an API that is pleasant to interact with in code as well. That the links/actions are enumerated is good for humans to learn how to manipulate the resource. That they have persistent rels is good for telling a computer how to do the same.

Think as an example. A human reading the HTML source will see that there's a related stylesheet available at "foo". But a program wanting to render HTML will check for the existence of links with rel="stylesheet".

1: https://datatracker.ietf.org/doc/html/rfc8288#section-2.1.2

Re: How did REST come to mean the opposite of REST?

#222

Post by mh- »

bombcar wrote: post #185
jaaron wrote: post #20

Earlier quoted context omitted.

> "This would suggest a restful api is not made for system-to-system communication, but requires human mediation at every step of the way" Which is exactly what REST was originally designed to do: provide an architecture for the Internet (not your app or service) that allows for humans using software clients to interact with services developed by programmers other than those which developed the clients. It was about…

Sounds very similar to (as far as I understand it) GOPHER.

My recollection is that using Gopher just felt more or less like browsing the early web with lynx. Simple text resources with hyperlinks.

Re: How did REST come to mean the opposite of REST?

#223

Post by emmelaich »

asiachick wrote: post #201

I hate when people change meanings too, but they do. What can you do about it? Complaining is like whining about all the words that have changed meanings over the decades. https://www.google.com/search?q=top+words+that+have+changed+... One I hate is "rougelike". I doesn't mean "like the game Rouge" (which might include Diablo and certainly includes Larn) Instead it now means any game with randomly generated levels bu…

*rogue :-)

Re: How did REST come to mean the opposite of REST?

#224

Post by janci »

lmm wrote: post #155
janci wrote: post #64

Earlier quoted context omitted.

Cont.: Because using HTTP verbs and status codes is stupid too: - the API is then tied to single "transport" protocol (it is application layer protocol in ISO/OSI but if you are not building a web browser, your application should reside one layer upwards) - it crosses ISO/OSI layer boundaries (exposes URLs in data, uses status codes for application error reporting, uses HTTP headers for pagination etc.) I think the s…

You know what else crosses ISO/OSI layer boundaries? Switches. But I don't see anyone saying hubbed networks are better. And realistically how often are you going to change your "transport"? And if you added an abstraction layer would that actually make it any easier? Stuff like SOAP ends up being the inner-platform effect where you reimplement all of HTTP on top of HTTP and actually implementing a new SOAP transport…

> You know what else crosses ISO/OSI layer boundaries? Switches.

No, they do not. Switches work at L2 and are only interested in L2 concepts (MAC addresses). They work transparently for any application that is not crossing the L1/L2 boundary. Routers are L3.

Re: How did REST come to mean the opposite of REST?

#225

Post by draw_down »

ahepp wrote: post #114

I'm walking away from this article unable to find a really good reason to implement HATEOAS in an API meant to be consumed by a program (as Application Programming Interfaces typically are). The best I can come up with (and this is me trying to like it) is that I guess the API is somewhat self documenting? I see benefits to resource orientation and statelessness, but why do people get so upset about these APIs not fo…

No post body was provided.

Re: How did REST come to mean the opposite of REST?

#226

Post by AtlasBarfed »

jonhohle wrote: post #218
mywittyname wrote: post #146

Earlier quoted context omitted.

People took the useful ideas and tossed the rest. The whole idea of embedding links into the data that describe available operations was not seen as useful, because most web pages already do that . That was not a problem that needed to be solved. But the concept of resource-oriented architectures which leveraged HTTP verbs to act on data with descriptive URIs was extremely useful in an era when interactions with web…

I’m not sure what the infatuation with HTTP verbs is. RPC allows modeling objects and arbitrary verbs. REST gives you a handful of verbs and punts on data modeling. It always seemed like a step back from an API design perspective. Definitely a battle I lost but never really understood the other side to begin with.

Standardization and a common language.

Limits.

Well developed error codes.

Rpc is a huge footgun.

What's annoying about rest is that it is a religion treated as a universal truth.

But really, rest is basically crud.

Re: How did REST come to mean the opposite of REST?

#227

Post by Linosaurus »

recursivedoubts wrote: post #47
Joeri wrote: post #7

The client knows nothing about the API end points associated with this data, except via URLs and hypermedia controls (links and forms) discoverable within the HTML itself. If the state of the resource changes such that the allowable actions available on that resource change (for example, if the account goes into overdraft) then the HTML response would change to show the new set of actions available. If the client kno…

I am the author and I agree with most of what you are saying here, REST and HATEOAS are for humans: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h... I disagree that it isn't an API, but that's a definition quibble. It is probably more profitable to talk about RESTful systems rather than RESTful APIs, since people think API == machines talking.

> It is probably more profitable to talk about RESTful systems rather than RESTful APIs, since people think API == machines talking.

If it's your stance that an interface designed to be interpreted by a program cannot be RESTful, then you could just shorten your rant to 'REST APIs cannot exist by definition'. It would save time. It's fair enough to be annoyed by words changing meaning I suppose.

It also seems like your RESTful system definition would include any server serving up straight html without client side scripting.

Re: How did REST come to mean the opposite of REST?

#230

Post by pojzon »

jaaron wrote: post #33
ocimbote wrote: post #9

I feel old for I have witnessed many of these battles. But I feel that I have seen history. There's nothing wrong in this article, in the sense that everything's correct and right. But it is an old person's battle (figuratively, no offense to the author intended, I'm that old person sometimes). It would be like your grandparents correcting today's authors on their grammar. You may be right historically and normativel…

This is me, 100%. I've seen enough to realize that progress is largely each generation re-thinking and re-mixing the previous generation's problems. Sometimes the remix makes things better, but plenty of times, older generation look at what's being done and says, "wow, you really don't understand what this was originally intended for" and there's a pain in that misunderstanding and inefficiency, watching work get red…

In Javascript world what you describe happens every two years.

At least to me it feels like it.

Post reply on HN