Rest – How to Distinguish When a 404 Status is Real in RESTFul Service

http-responserest

We have ServiceA with these endpoints defined:

/devices:
  get:
    queryParameters:
      make:
        type: string
        repeat: false
        required: false
      model:
        type: string
        repeat: false
        required: false
    responses:
      200:
        body:
            schema: Devices
        500:
          body:
               text/plain:
  /{deviceId}:
    uriParameters:
      deviceId:
    get:
      responses:
        200:
          body:
            schema: Device
        404:
          body:
               text/plain:
        500:
          body:
               text/plain:

If no devices match a request to /devices?make=x&model=y, an empty list of devices is returned with a 200 status. If no device matches a request to /devices/badDeviceID, a 404 is returned.

We have another service which calls this one. The problem we're encountering is that we want to return a 500 service error from the second service if the first service is down. If a 404 is returned from the server for calls to /devices?make=x&model=y, we know the service is actually down/unreachable. But for calls to /devices/badDeviceID, we can't tell if the device just doesn't exist or the service is down.

Has anyone else had this situation? How did you handle it?

Our services are written in Java and deployed to an application container, in our case JBoss EAP. If EAP is up and running but the individual service is not deployed or currently disabled, EAP will return a 404 to the caller. It is this case that we can't distinguish from when the service is deployed/available and the resource couldn't be found.

Best Answer

Based on the description, you are returning a 404 error in the situation where the service is down or unreachable. This is not an appropriate response for that situation. 4xx errors are for problems with the user request. The situation that a service is down or unreachable should be a 5xx error.

Based on the extra detail you provided, I think you can manage this by mapping in a simple app at a less specific context. For example, say your devices app is mapped on the server at app/devices. You could create a trivial application that you map to app that simply returns a 500 class "service down" error. When the devices app is running, it will be more specific and handle the requests. If it's not there, your 'service down' web-app takes over.

Related Topic