FreeBSD and REST should organize the Is It Dead Yet? conference.
Just to clarify, my incredibly vague point is that people having been saying FreeBSD and now REST are or should be dead for so long but they never die :)
It's time to put REST to rest
81–85 of 85 posts
Re: It's time to put REST to rest
#82Earlier quoted context omitted.
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
I still prefer 200 with an empty list for the 'no results' case. The same client code works, rather than having to code for 204.
- If I query for an identifier which doesn't exist - Server replies 404, this should fall into my error handling as there's a data inconsistency
- If I query say like ?category=automotive&price=1 and I get a 200 containing a json body in which there's an empty list of matches, then my client code can handle 0 matches as well as 1 or 10 with no special handling.
Re: It's time to put REST to rest
#83Earlier quoted context omitted.
Exactly. If you ditch the bikeshedding and no true scot arguments, REST is just a loosely defined naming convention around HTTP verbs, that almost every company I have been apart of agrees on / disagrees on certain minor aspects. That being said, I am thankful that we moved to using some form of "REST" (however you define it) as it was infinitely better than WSDL/SOAP. gRPC is nice in some areas, but these days I fin…
If you define the terms exactly the way I want, then I win the argument! It's a very useful technique.
yawaramin, my former reasonML brother, you won't remember me, but I am so happy to have you comment on my comment even if it is tongue in cheek! Hope all is well.
Re: It's time to put REST to rest
#84Earlier quoted context omitted.
If you define the terms exactly the way I want, then I win the argument! It's a very useful technique.
yawaramin, my former reasonML brother, you won't remember me, but I am so happy to have you comment on my comment even if it is tongue in cheek! Hope all is well.
ReasonML–that brings back good memories! :-D
To be honest, I was pulling your leg but I mostly do the same thing you're doing when dealing with APIs at work :-P
Re: It's time to put REST to rest
#85I 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
I don't like how undiscoverable it is, and how it blocks browser-based debugging. I'd much rather be able to open an issue with a GET link to a stable representation, where possible.
Cloudflare doesn't support it for caching (more specific Cloudflare doesn't obey the Vary: cache header).