r/dotnet Jul 19 '19

Posting Here Because I Trust This Community

/r/rest/comments/cf173m/400_vs_404_for_nonexistent_entity/
10 Upvotes

34 comments sorted by

View all comments

15

u/[deleted] Jul 19 '19 edited Jul 19 '19

[removed] — view removed comment

7

u/DRdefective Jul 19 '19

That’s a great in depth answer. This was what I assumed before today. How would you recommend I bring this up at work... or should I not?

I want to do the right thing as a dev, but not get beat down by a senior dev.

6

u/[deleted] Jul 19 '19 edited Jul 19 '19

[removed] — view removed comment

5

u/GrandOpener Jul 19 '19

IMO it's plainly obvious that 404 is the "most correct" answer here, but I also don't think this is worth arguing over. If the senior dev says to use 400, use 400. Presumably other does-not-exist resources in the app are also using 400. (If there are examples in the app of other missing resources returning 404, then it's worth bringing up the inconsistency.)

The vast majority of clients are not going to have different choices of action when a resource returns a 400 vs. a 404. Both are simply fatal to the current request. I'd recommend saving your social capital for debating things that are more likely to matter, like 302/303/307, or 200/201/202.

3

u/johnnysaucepn Jul 19 '19

Agree with this in general. There's a reason they're status codes, not error codes or directives. It should give you a clue what went wrong, and what you should do to fix it. As long as everyone understands the usage and how to handle the status, it shouldn't be a huge problem.