I agree, I am absolutely not a fan of this. REST is about documents; documents do not contain status information about the transport protocol used to transfer them, they just contain the free-form data that the application wants to convey to you.
For example, imagine the document at /foo/bar has moved to /new-api/foo/bar. Well, if you use HTTP for status, the server sends a 302 redirect when you try to request /foo/bar, and the user agent automatically grabs /new-api/foo/bar. If we reinvent this wheel for some reason, you can't use HTTP clients anymore, you have to use some proprietary bullshit client instead.
No thanks. This is not a problem and it does not need a "solution".
(I also agree about 204 responses for DELETE requests. The thing is gone, why does any data need to be sent back other than, "yeah, it went away"?)
The document is now in the data field of the returned JSON. It's just an extra header/footer, similar to having meta http-equiv tags. Because it helps limited HTTP clients like JSONP, many web APIs already use this form, but they all use different syntax, which is the problem this "standard" is addressing.
Comments
I agree, I am absolutely not a fan of this. REST is about documents; documents do not contain status information about the transport protocol used to transfer them, they just contain the free-form data that the application wants to convey to you.
For example, imagine the document at /foo/bar has moved to /new-api/foo/bar. Well, if you use HTTP for status, the server sends a 302 redirect when you try to request /foo/bar, and the user agent automatically grabs /new-api/foo/bar. If we reinvent this wheel for some reason, you can't use HTTP clients anymore, you have to use some proprietary bullshit client instead.
No thanks. This is not a problem and it does not need a "solution".
(I also agree about 204 responses for DELETE requests. The thing is gone, why does any data need to be sent back other than, "yeah, it went away"?)
The document is now in the data field of the returned JSON. It's just an extra header/footer, similar to having meta http-equiv tags. Because it helps limited HTTP clients like JSONP, many web APIs already use this form, but they all use different syntax, which is the problem this "standard" is addressing.