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

It's time to put REST to rest

sollecitom.github.io

Post reply on HN
Print view View original

71–80 of 85 posts

Re: It's time to put REST to rest

#71

Post by michaelsbradley »

recursivedoubts wrote: post #7

OK OK OK, OK OK, stay calm, Carson, stay calm... I'd like to just leave a few links on REST here for the reader's consideration: https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... https://intercoolerjs.org/2016/01/18/rescuing-rest.html https://htmx.org/essays/two-approaches-to-decoupling/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/hypermedia-clients/ https://intercooler…

> All these so-called “REST-ful” APIs are really JSON/RPC.

The situation is even worse than that because JSON-RPC is well specified:

https://www.jsonrpc.org/specification

These so-called "REST-ful" APIs are often ad hoc RPC, underspecified in many respects, and make a twisted mess of HTTP semantics and request/response payloads; and when an edge case or shortcoming is discovered, the API sprouts more wild hairs.

What's even more "fun" is when you look through the project's history and discover that at some point, someone/s on the team fixed the problem by introducing proper JSON-RPC (per spec). Maybe they even got pretty far along with cleaning up most/all of the API. But then they moved on or got pushed aside. Other devs didn't like the JSON-RPC system ("too verbose", "too much effort to refactor/whatever") and started sprouting new "REST-ful" endpoints so they can, you know, get things done faster!

Re: It's time to put REST to rest

#72

Post by the_gastropod »

munk-a wrote: post #50
nesarkvechnep wrote: post #27

Earlier quoted context omitted.

You use REST every day. HTML is REST. Yes, with HATEOAS.

Well, not all of REST - the discoverability portion isn't supported by pretty much anyone (because, IMO, it's just not useful).

I think you missed the point. You 100% use it every day. You’re using it on this website right now. Your web browser shows you what actions you’re able to take against the HN api. Neat, huh?

Re: It's time to put REST to rest

#73

Post by Turing_Machine »

gweinberg wrote: post #51
stronglikedan wrote: post #17

Earlier quoted context omitted.

> without a specific UI for it None of my browsers seem to have PUT, PATCH, and DELETE baked into the standard UI (or even POST really), so maybe it is true?

I just checked the MDN docs https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fo... The only allowed form methods are get, post, and dialog. So you can't do put, patch, or delete via a form.

Sure you can. You just can't specify it as a form action.

There's nothing to stop you from using form elements to get your user inputs as normal, then wiring up your own "submit" button that calls your own Javascript to use any method you want. JS fetch, for example, lets you put anything you want in the method: field. I think you can even specify custom methods that only have meaning for your specific server-side code.

Re: It's time to put REST to rest

#74

Post by Turing_Machine »

lolinder wrote: post #48
quickthrower2 wrote: post #33

Earlier quoted context omitted.

They mean you can’t interact with a raw API from the browser. Unless you are just doing vanilla gets. You might use a REST client instead or what some services do is offer a playground coded in JS to play with the end point but such a playground needs to deal with CORS.

But this also isn't true—fetch can run all the HTTP request verbs. What they seem to mean is that you can't access most of them via the GUI directly, which is true, but their "solution" is to make queries and commands both use POST, which means they've now thrown away the ability to even access read-only endpoints via the GUI.

> But this also isn't true—fetch can run all the HTTP request verbs.

Yep, or even custom ones that you've defined for specialized purposes (obviously you have to make sure your server also understands them).

Re: It's time to put REST to rest

#75

Post by gregors »

there's a reason why REST is still the most widely used and the RPC type examples have faded.

Here's the thing, domain specific language specification both in source code and at various API interaction points are a good thing. But they are a thing that takes time to figure out, and they have a tendency to change. REST is still the best starting point and I challenge anyone to say that RPC is "better". We've tried it before it wasn't better. Oh you mean we did it wrong? Well now, that's the real trick isn't it?

Re: It's time to put REST to rest

#76

Post by adonese »

simonw wrote: post #18

I agree with some of this - I've never found value in the different PUT/PATCH/etc verbs, and I think the lack of examples of good "pure" REST APIs indicates that pure REST doesn't work easily for most projects. I do think this throws away some pieces that are really valuable though: 1. URLs for concepts are a good idea 2. Distinguishing between read-only operations (which can be cached) and write operations using GET…

Content negotiation is it just for taste or do you have some other reasons?

I find one good use case for them when a browser can make good use case with a SSE whilst another client just needs a regular _json_ response

Re: It's time to put REST to rest

#77

Post by nyantaro1 »

recursivedoubts wrote: post #7

OK OK OK, OK OK, stay calm, Carson, stay calm... I'd like to just leave a few links on REST here for the reader's consideration: https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... https://intercoolerjs.org/2016/01/18/rescuing-rest.html https://htmx.org/essays/two-approaches-to-decoupling/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/hypermedia-clients/ https://intercooler…

I see what you did there

Re: It's time to put REST to rest

#78

Post by Banditoz »

benrow wrote: post #57
ilovefood wrote: post #43

The article is good, and I get the point. However, from experience, this: > POST on /queries/enlisted-students-on-joining-date/version/1 { "date": "2023-09-22" } to retrieve all students that joined on a given date. always ends up in a complete and absolute mess, where every possible query gets it's own random name, different parameters, ending up with duplicates all over the place. Also, while it can be possible to…

I like the convention: - 404 if resource requested by id - 200 with empty list of results if it was a 'search' type request with params (not referring directly to an id)

What about 204? https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204

Re: It's time to put REST to rest

#79

Post by quickthrower2 »

lolinder wrote: post #48
quickthrower2 wrote: post #33

Earlier quoted context omitted.

They mean you can’t interact with a raw API from the browser. Unless you are just doing vanilla gets. You might use a REST client instead or what some services do is offer a playground coded in JS to play with the end point but such a playground needs to deal with CORS.

But this also isn't true—fetch can run all the HTTP request verbs. What they seem to mean is that you can't access most of them via the GUI directly, which is true, but their "solution" is to make queries and commands both use POST, which means they've now thrown away the ability to even access read-only endpoints via the GUI.

Ok I accept that - I guess you could F12, drop into the console and then fetch. Which is broadly similar to using curl.

I also don't like the idea of making queries and commands use POST. It kind of sucks (unless you are doing it for a website that is trying to avoid using JS for some reason).

Post reply on HN