News for hackers. Stuff that matters.
Re:REST was never about CRUD by cimmanom on Thursday July 19, 2018 @12:23PM (#17567815)
That seems like a bug with the external system. 4xx means the request needs to be corrected to achieve success. 2xx means success, even if success means "deleted".

If a system treated 5xx responses as successful, you'd consider that a problem with the system's response handling, not a problem with your own communication of state. So why consider abuse of 4xx to be a problem with the communication protocol?

Re:REST was never about CRUD by stickfigure on Thursday July 19, 2018 @06:45PM (#17571005)
The external system didn't define the API; the service did. If you poke around on stackoverflow, you'll find quite a number of answers recommending this pattern. It's a bad idea, but it's not uncommon.
Re:REST was never about CRUD by eridius on Friday July 20, 2018 @03:28AM (#17573120)
Recommending what, that a `DELETE /foo/bar` should return a 404 on success? That's flat-out wrong. It should return a 204 No Content. A subsequent `GET /foo/bar` should return a 404, but presumably the message queue isn't doing a subsequent GET but is inspecting the result of the DELETE.
Re:REST was never about CRUD by cimmanom on Friday July 20, 2018 @07:54AM (#17574230)
Ok. But again, a bad design choice doesn’t mean using HTTP error codes is a bad idea. It means that like with anything else you need to know your tools.