2

I am implementing some REST based web services - which is working wonderfully so far. I have been following the advice of Vinay Sahni (http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api).

I've realised a potential problem with the idea of using a "404" to indicate when an entity in a service is not found. This is based on the idea to Hijack the HTTP protocol's 404 error response - since it's already there and available.

In the case that there is a problem with the web service - ie. A Tomcat redeploy fails... calling a web service will result in a 404 regardless of if the entity actually exists, or the URL is actually not available.

Is it not ideal to use a 404 for this reason? I feel that someone out there has run in to the same potential problem.

Stephen Ostermiller
  • 23,933
  • 14
  • 88
  • 109
om3ga
  • 21
  • 3
  • Related somewhat to this: http://stackoverflow.com/questions/23267329/discriminating-between-infrastructure-and-business-logic-when-using-http-status/ – Brian Kelly May 22 '14 at 01:48
  • Thanks, I didn't find this earlier when searching. – om3ga May 22 '14 at 02:36

1 Answers1

0

When a requested entity is not found you should use 404 Not Found. Period. If your server deploy failed, clients should get a 5xx error, not a 4xx error.

You shouldn't design your application around your infrastructure shortcomings. If you need circumvent those shortcomings, you should do it in ways that are decoupled from your application, like middlewares, proxies, etc.

Pedro Werneck
  • 40,902
  • 7
  • 64
  • 85