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

251–260 of 393 posts

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

#251

Post by pjmlp »

Because REST as designed while it might be some academic ideal, doesn't make sense in distributed computing performance point of view.

Needless network requests to understand what a REST API is supposed to be able to do, and then navigate through their description, until the actual call can be finally be done.

And then even if it isn't pure REST, we have all those global warming contributions out of needless parsing.

Thankfully with the uptake of gRPC we are getting back to protocols where network performance is taken into consideration.

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

#252

Post by bigDinosaur »

mappu wrote: post #250
bigDinosaur wrote: post #237

Earlier quoted context omitted.

Why can't you do a 404 + message?

HTTP is just a transport for your RPC. It's an implementation detail. At the HTTP layer, the transport was successful, so a 200 is appropriate. A 404 would indicate 'not found' at the transport layer e.g. a bad proxy configuration or you didn't hit the right server at all. You definitely wouldn't confuse it with '${my_widget} not found'.

This is absolutely counter to everything HTTP is supposed to be used for. I'm not quite sure how to even respond.

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

#253

Post by vrnvu »

bigDinosaur wrote: post #252
mappu wrote: post #250

Earlier quoted context omitted.

HTTP is just a transport for your RPC. It's an implementation detail. At the HTTP layer, the transport was successful, so a 200 is appropriate. A 404 would indicate 'not found' at the transport layer e.g. a bad proxy configuration or you didn't hit the right server at all. You definitely wouldn't confuse it with '${my_widget} not found'.

This is absolutely counter to everything HTTP is supposed to be used for. I'm not quite sure how to even respond.

It's a common discussion with HTTP Status Codes. Application vs Transport layer. HTTP status are a mix of both and it can be misleading.

A couple of weeks ago there was an interesting post about this topic here in HN.

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

#254

Post by ahtihn »

mappu wrote: post #250
bigDinosaur wrote: post #237

Earlier quoted context omitted.

Why can't you do a 404 + message?

HTTP is just a transport for your RPC. It's an implementation detail. At the HTTP layer, the transport was successful, so a 200 is appropriate. A 404 would indicate 'not found' at the transport layer e.g. a bad proxy configuration or you didn't hit the right server at all. You definitely wouldn't confuse it with '${my_widget} not found'.

If you serve static content with nginx or any other webserver, you'll get 404 for any file that doesn't exist.

Why should '${my_widget} not found' be different?

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

#255

Post by mike256 »

mappu wrote: post #250
bigDinosaur wrote: post #237

Earlier quoted context omitted.

Why can't you do a 404 + message?

HTTP is just a transport for your RPC. It's an implementation detail. At the HTTP layer, the transport was successful, so a 200 is appropriate. A 404 would indicate 'not found' at the transport layer e.g. a bad proxy configuration or you didn't hit the right server at all. You definitely wouldn't confuse it with '${my_widget} not found'.

This is about REST, not RPC.

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

#256

Post by eterevsky »

If you are designing a REST API, please don't follow this author's advice and return HTML instead of JSON. HTML takes much longer to parse and makes the API more fragile.

The history did its job: it preserved the most useful features of the original idea (expressing RPCs as URLs in GET and POST requests) and has dropped the unnecessarily complicated bits.

What this article is about is a pedantic terminology battle of whether to call the current practice REST or not.

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

#257

Post by jasonboyd »

kelseyfrog wrote: post #233
quickthrower2 wrote: post #216

Earlier quoted context omitted.

What do they do if they don’t hard code it? bookHotelUri = listHotelResponse.data.urls[4]; Or listHotelResponse .data.urls.find(u=>u.action===‘book’).url ?

Sort of. Verbs are still eschewed so rather than finding a 'book' link, it would be a 'booking' link to which a POST could be made to create a new booking. As a note, "Booking" is a confusing example because while a hotel booking is a noun it at first glance reads as a progressive tense verb.

So instead of a hard coded url it's a hard coded reference to a url? How does it deal with a breaking changing? Say the order of the links changes? It doesn't seem like this works without some out of band information.

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

#258

Post by [deleted] »

int_19h wrote: post #181
ocimbote wrote: post #89

Earlier quoted context omitted.

Highly debatable. A (too quick?) Darwinist perspective would tell us that the original ReST was not fit. And the "new" ReST (aka, JSON-RPC) is more fit. Fit in its current ecosystem, of course.

That's exactly what I meant. The "new REST" appropriated the term because it's what's actually being used. The "old REST" didn't get a new term because it's not actually being used. There are still theoretical discussions around "old REST", but they all have "new REST isn't REST at all" as their core point, so the lack of new terminology is deliberate there.

[deleted]

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

#260

Post by mike256 »

int_19h wrote: post #181
ocimbote wrote: post #89

Earlier quoted context omitted.

Highly debatable. A (too quick?) Darwinist perspective would tell us that the original ReST was not fit. And the "new" ReST (aka, JSON-RPC) is more fit. Fit in its current ecosystem, of course.

That's exactly what I meant. The "new REST" appropriated the term because it's what's actually being used. The "old REST" didn't get a new term because it's not actually being used. There are still theoretical discussions around "old REST", but they all have "new REST isn't REST at all" as their core point, so the lack of new terminology is deliberate there.

We use the old REST a lot and call that what you name "new REST" Json-RPC. What's so difficult about naming things what they are? I mean Devs do have some brain. That's why we are able to write cool software. But then why are some of us too stupid to get that REST thing right?
Post reply on HN