How did REST come to mean the opposite of REST? • Hacker News Board

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

#271

Post by ribit » Tue, Jul 19, 2022, 7:28 AM UTC

I am not quite sold on the dichotomy between “REST” and “RPC” as suggested by the article: if sending over a structured response that has to be interpreted by a client program is considered RPC then why is sending over a structured response that has to be interpreted by the browser not RPC? REST as described by the article is by definition a subset of RPC - you invoke a remote procedure, you get a response. Besides, it stands to reason that the stateless properties of REST are much more interesting than the “returns a hypermedia response” but.

As to the rest (pun) of the article… I have no problem accepting that REST was originally proposed as a way to navigate the web using hypermedia responses. But I also have no problem in accepting that the term has since moved on to describe the API design principles which ultimately what makes it useful for the modern web.

Funnily enough, recent interest in SSR almost makes it a full circle.

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

#272

Post by number6 » Tue, Jul 19, 2022, 7:29 AM UTC

ahtihn wrote: post #254

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

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?

The Webserver Servers a file or an endpoint. This file or endpoint have indeed be found. On this layer the transaction was successful.

So if you return 404 on this layer you are saying that whatever file or endpoint you searched is not there.

If you ask for a resource at an endpoint that does not exist e.g. via an parameter in the url and return 404 it is not clear if the endpoint does not exist e.g. the endpoint.php is missing or the resource you are looking for. Leading to questions like: is the endpoint down, is my internet wonky, did I misspell the name, and business logic related questions: is there no such widget, is the widget out of stock, should I call another endpoint?

404 does not indicate non existence but it indicates an inability to be found by the server. It's a nuance and it only matters when it does and then it bites...

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

#273

Post by eterps » Tue, Jul 19, 2022, 7:38 AM UTC

jayd16 wrote: post #123

Here's the crux of the argument but it falls flat IMO: >A proper hypermedia client that receives this response does not know what a bank account is, what a balance is, etc. It simply knows how to render a hypermedia, HTML. No true client would know how to display json or not know how to display html. So if you have a browser plugin that pretty prints json, it's RESTful? Seems pretty specious.

> a browser plugin that pretty prints json, it's RESTful?

Only if its a hypermedia rendering (for a example it renders hypertext so the end-user can interact with the system).

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

#274

Post by z9znz » Tue, Jul 19, 2022, 7:40 AM UTC

Author says that the json is not self-describing, but the html example is... That's true if "self describing" means "describes html structure".

Perhaps modern use of the term REST is officially incorrect, but I think most REST clients really need to understand what they are receiving. How many rest clients merely show the result (as-is) to the human user? No, most clients are themselves programs which need to consume the response and make further decisions.

Imaging having to parse out the official REST HTML response to get the balance of the account. I hope the source is only in one language, because I would hate to have to build my own reverse-localization system just to make sense of the REST response I just consumed.

I was really trying to grasp why someone would build such a tall soapbox to complain about the incorrect use of a term, when the correct use would mean building arguably near-useless APIs. But then I took a look at what the htmx site is all about. It's about everything-as-html. "Note that when you are using htmx, on the server side you typically respond with HTML, not JSON. This keeps you firmly within the original web programming model, using Hypertext As The Engine Of Application State without even needing to really understand that concept."

Looking at the rest of their site, I'm finding it very difficult to see the value proposition over the current approach of JSON APIs.

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

#275

Post by z9znz » Tue, Jul 19, 2022, 7:42 AM UTC

eterevsky wrote: post #256

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…

This article really is about getting people to use their overloaded HTML libraries.

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

#276

Post by andybak » Tue, Jul 19, 2022, 7:51 AM UTC

irrational wrote: post #265

jonhohle wrote: post #218

Earlier quoted context omitted.

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.

Yes, people who use put and delete (and any other verb other than post and get) come off as insufferable bores to me. Heck, you just use GET and it will work fine 99% of the time.

And that 1% is a killer. Ask the people who had content deleted because of a GET API and bad interactions with pre-fetching and caching.

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

#277

Post by eterps » Tue, Jul 19, 2022, 7:58 AM UTC

z9znz wrote: post #274

Author says that the json is not self-describing, but the html example is... That's true if "self describing" means "describes html structure". Perhaps modern use of the term REST is officially incorrect, but I think most REST clients really need to understand what they are receiving. How many rest clients merely show the result (as-is) to the human user? No, most clients are themselves programs which need to consume…

> That's true if "self describing" means "describes html structure".

> Imaging having to parse out the official REST HTML response to get the balance of the account.

It's not the HTML that matters, it could be any self describing format containing hypermedia controls, for example: https://jasonette.com or https://hyperview.org

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

#278

Post by dncornholio » Tue, Jul 19, 2022, 7:58 AM UTC

This guy.. I do whatever the fuck I want. Why does this person feels the need how to write my API and what I should call it?. This guy's obviously living in a cocoon. Who even uses the term hypermedia?

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

#279

Post by Cthulhu_ » Tue, Jul 19, 2022, 7:59 AM UTC

The argument seems to be that modern-day REST is not self-descriptive, but... making it so is a lot of extra work for little benefits; people have optimized for efficiency and focus on what they need.

The links in a JSON response are only applicable if you need a client to be able to explore from the response on, but in practice it's not necessary and you're better off saving the response overhead.

A high over design like an OpenAPI spec is better in all the cases I've seen. And of course there's alternatives like GraphQL or grpc depending on the use case. I'd still prefer REST for public APIs though.

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

#280

Post by robertlagrant » Tue, Jul 19, 2022, 8:23 AM UTC

irrational wrote: post #265

jonhohle wrote: post #218

Earlier quoted context omitted.

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.

Yes, people who use put and delete (and any other verb other than post and get) come off as insufferable bores to me. Heck, you just use GET and it will work fine 99% of the time.

Having GET commonly understood as idempotent is ergonomic.