> Thus -- as REST is /the/ canonical "hijack HTTP status codes to mean something clever" paradigm -- your article is /entirely/ in context of REST.
Oof, that's a hell of a good point. So much for that plan lol
> Anyway - I'm entirely with you on the foolishness of using 404 to mean both "your URL is messed up" and "I couldn't find the resource you wanted". Seems like, for REST, you'd want to return a 400 (malformed request) or something if your URL was borked rather than overloading 404.
Yup, that's the headache I'm trying to muddle my way through.
Really it's less "this is how to build APIs" and more "have you considered your consumer when you return data?". But I think even in that context your point stands better.
Back to the drawing board it seems.
At least I can generate more content now :D
Oof, that's a hell of a good point. So much for that plan lol
> Anyway - I'm entirely with you on the foolishness of using 404 to mean both "your URL is messed up" and "I couldn't find the resource you wanted". Seems like, for REST, you'd want to return a 400 (malformed request) or something if your URL was borked rather than overloading 404.
Yup, that's the headache I'm trying to muddle my way through.
Really it's less "this is how to build APIs" and more "have you considered your consumer when you return data?". But I think even in that context your point stands better.
Back to the drawing board it seems.
At least I can generate more content now :D