GET /api/add-a-comment?message=disagree
You’re using GET to Post a comment. Feels like another method is more appropriate.
Update: It clicked now…
What it means for an API to be RESTful
21–30 of 59 posts
Re: What it means for an API to be RESTful
#22Earlier quoted context omitted.
'(to) comment' is already a verb.
GET, COMMENT, PUT, UPDATE, DELETE. Yeah, makes sense. Now we only need an alternative for PUT to backcronym CRUD. RIPOSTE?
I was referring to that the PATH could just be named /api/comment?... , because comment is already a verb.
Re: What it means for an API to be RESTful
#23whole thing about RESTful api - majority of people never understood it - few people like the htmx crowd tried to bring it up again to teach people the right way.
but people who didn't understand rest some of them migrated to graphql or rpc.
Re: What it means for an API to be RESTful
#24REST seems to bring out people who like to define specs and correct others on following the spec or not. There are many other things in tech like this. To be honest, I just kind of don't understand the point. Could my API be better following some of these rules the author presented? Probably. But by how much? Is it worth it? When someone else on my team disagrees do we go back and argue about the spec again? After 12…
The point is to externalize the thinking about the desired nirvana state, so that you don't need to thing about them, when you code your API.
Re: What it means for an API to be RESTful
#25Re: What it means for an API to be RESTful
#26REST seems to bring out people who like to define specs and correct others on following the spec or not. There are many other things in tech like this. To be honest, I just kind of don't understand the point. Could my API be better following some of these rules the author presented? Probably. But by how much? Is it worth it? When someone else on my team disagrees do we go back and argue about the spec again? After 12…
The point is to externalize the thinking about the desired nirvana state, so that you don't need to thing about them, when you code your API.
Sure, ideally, but if no one can agree on the spec (as evidenced by the need for these types of articles,) then it's not really saving me much effort is it?
Better to just pick something and go with it, then argue about the spec more
Re: What it means for an API to be RESTful
#27Re: What it means for an API to be RESTful
#28REST seems to bring out people who like to define specs and correct others on following the spec or not. There are many other things in tech like this. To be honest, I just kind of don't understand the point. Could my API be better following some of these rules the author presented? Probably. But by how much? Is it worth it? When someone else on my team disagrees do we go back and argue about the spec again? After 12…
I think the problem is primarily if you publish a REST api for commercial consumption on some level. If people depend on your REST api, the "RESTfulness" of it affords you some level of inaccuracy when documenting how things work.
But that said, I'm okay with it not following the spec as long as things are clearly documented to end users. We just went through an issue where a prominent CDN provider exposing a REST API we depend on broke REST in a very important way (i.e. NOT stateless). It's extremely annoying to try and construct clients around nonstandard APIs, and the more REST-y, the less annoying.
Re: What it means for an API to be RESTful
#29Many years ago as a young developer I read Fielding's dissertation, Fowler's writings on the Richardson Maturity Model and even a book (don't remember the title) on the topic. Then I spent the next dozen years creating, reading, updating and deleting JSON APIs.
Problem Details (RFC 9457) are useful and have made an occasional appearance, but actual hypermedia driven APIs with custom media types seem to be non-existent outside of example blog posts. It's much more common to instead see APIs overload lesser-used HTTP status codes with their own domain-specific meanings. But if I'm being honest, this sort of protocol crime almost never caused an actual problem in practice.
The advocacy for "true REST" is missing a compelling argument and useful example of why it would actually be an improvement. Despite its prominence, for over 20 years almost nobody has used this approach. Why is that?
I do still have an aesthetic appreciation for "true REST", but in practice I find the fact that nobody uses it to be mainly useful in ending bikeshedding discussions. Once you understand your API isn't RESTful to begin with, there's no longer any point in arguing if 411 or 412 is the more RESTful status code to use when a user attempts to order a product without specifying a quantity. (Spoiler: neither is correct) You simply send a 400 with Problem Details and call it a day. Ironically, this indifference may make your API just a little bit more RESTful.
Re: What it means for an API to be RESTful
#30Many years ago as a young developer I read Fielding's dissertation, Fowler's writings on the Richardson Maturity Model and even a book (don't remember the title) on the topic. Then I spent the next dozen years creating, reading, updating and deleting JSON APIs. Problem Details (RFC 9457) are useful and have made an occasional appearance, but actual hypermedia driven APIs with custom media types seem to be non-existen…
> Despite its prominence, for over 20 years almost nobody has used this approach. Why is that?
There is one highly successful use of REST: the World Wide Web.
The Web/Web browsers are driven from hypermedia. (This is circular, as Fielding was looking at the web when making his dissertation.)
Granted, Web browsers stand alone as an application with extreme flexibility.
So REST is both highly common and very rare, depending on how you count.