No, it's not.
But in short, articles arguing thst the most popular api format needs to be put to rest can't be anything else but highly opinionated clickbait
It's time to put REST to rest
41–50 of 85 posts
Re: It's time to put REST to rest
#42FreeBSD and REST should organize the Is It Dead Yet? conference.
Re: It's time to put REST to rest
#43The 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 cache these POST requests (responses), it's additional work and more friction compared to REST. I'm not convinced the tradeoff is worth it in this particular case.
All in all, I don't know if the current proposal can be an alternative either but the idea of a "REST-lite" goes in the right direction and it's a great start.
However this is a complete no for me:
> When a requested student is nonexistent, your API can return 200 OK HTTP status code with a { "user": null, "message": "No user exists with the specified ID" } response body.
If nothing is found, I want a 404! :D
Re: It's time to put REST to rest
#44I thought a practical benefit of REST (probably the only one I really care about) is that it makes APIs more scalable by allowing caching proxies to safely cache responses to GET requests? At least I thought that was a big part of the original pitch, but I don't see it mentioned here.
Re: It's time to put REST to rest
#45Earlier quoted context omitted.
It's kinda true if you're thinking purely about submitting requests through ` ` elements - but even then you can bend browsers to support other verbs.
There are multiple RFCs with lists of HTTP verbs and axios only supports the more limited set, which for my particular legacy project meant I couldn't use any of the creative ones.
That really just sounds like an axios issue - I've built in support for custom verbs with nothing but plain-old ES5 javascript. The verb is nothing more than a string component of the HTTP request and it's pretty trivial to modify it to your liking (even outside of standard verbs!).
Re: It's time to put REST to rest
#46As a REST enthusiast I was excited to read this and learn a new perspective but this section > The “benefits” REST is supposed to introduce Is one of the more egregious straw men I’ve seen in a while. Never once in my twenty years have I heard anyone say it’s nice because “you don’t have to read the docs” or “it works in a browser” REST helps with lots from thinking through clean data models to helping ensure consist…
> Never once in my twenty years have I heard anyone say it’s nice because “you don’t have to read the docs” or “it works in a browser.
I've seen multiple people argue these points. shrug
Re: It's time to put REST to rest
#47REST is a design pattern. Do you use the bridge pattern for all your Java code? Nah! Do you use an ORM for all your data access and never drop down to SQL? Nah.
Re: It's time to put REST to rest
#48> About being able to use a RESTful API directly from a browser: browsers only use the GET and POST HTTP methods, among the ones REST associates meaning to. You cannot use a RESTful API from the browser, because the PUT, PATCH, and DELETE methods are not used by the browser, and even the POST method cannot be used without a UI. Also, even if you could, APIs are for machines, not humans. The user experience would be d…
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.
Re: It's time to put REST to rest
#49There are some things that simply don't fit into the REST structure, the most common one for me is bulk operations. Operating on multiple instances of a specific resource is a common thing, and you need a non-REST endpoint to do it properly. Of course you could just iterate over the items, but then you can never have transactional behaviour (either no write happens or all of them happen). And of course it's terribly slow for larger number of items.
Another annoyance is GET endpoints with complex filters like e.g. the index route for a specific resource. It's really annoying to be limited to the query params instead of a request body for that.
Re: It's time to put REST to rest
#50Earlier quoted context omitted.
Well, if we're being truthful, none of us use REST. We're all just cherry-picking the parts of it that work for our organizations... and that's absolutely fine . The programtic discoverability portion of REST always struck me as pretty poorly thought-out anyways.
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).