1

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.

Improve this question
6
  • Apparently JBoss errors can be configured, at least somewhat. See here for a starting point: developer.jboss.org/thread/271392?_sscc=t
    – Robert Harvey
    Commented Mar 15, 2018 at 16:07
  • That sample seems to be changing what page is displayed on a 403 error, not changing the error. But, I'll dig deeper into the possibility of configuring EAP to return a 500 instead of 404.
    – sdoca
    Commented Mar 15, 2018 at 16:15
  • First question. Are you consuming the 1st service directly (ip:port)? Or is there a proxy/gateway? Second question: For what reason do you need to know whether a 404 is due to business or due to infraestructure? Is it expected the http client to behave in different ways according to these scenarios?
    – Laiv
    Commented Mar 15, 2018 at 20:53
  • 1
    Third question: why a valid query (#1) cause 404 when nothing is found? Is It expected to respond with a single and unique resource? If not, could you return 200 + empty array?
    – Laiv
    Commented Mar 15, 2018 at 21:04
  • @Laiv 1. We are connecting via a load balancer but no proxy. 2. The client service should return a 500 error if downstream services are unavailable. Therefore, it needs to differentiate. 3. Yes, the downstream service is expected to return a single/unique resource. If it doesn't exist, as per RESTful convention/standard a 404 is returned. Empty arrays are expected to be returned when a query returns a collection, not a single instance.
    – sdoca
    Commented Mar 16, 2018 at 22:15

2 Answers 2

Reset to default
2

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.

Improve this answer
6
  • Well, that's not exactly clear from the question. But even if he changed the status code, the problem that he posed still remains: there's no way to tell from just the status code what the specific problem is. HTTP status codes were never intended to be comprehensive.
    – Robert Harvey
    Commented Mar 15, 2018 at 15:29
  • If the service is down, the application container (in our case JBoss EAP) returns a 404.
    – sdoca
    Commented Mar 15, 2018 at 15:44
  • @RobertHarvey "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." Seems pretty clear to me. What am I missing?
    – JimmyJames
    Commented Mar 15, 2018 at 15:46
  • @sdoca That's a problem and if you can fix that, you'll be in a better place. I would recommend moving to an embedded HTTP solution such as embedded Jetty or Tomcat so you won't have a situation where the app server is up but the service is down but I don't know if you can affect that change.
    – JimmyJames
    Commented Mar 15, 2018 at 15:48
  • @JimmyJames Switching servers is not an option for us.
    – sdoca
    Commented Mar 15, 2018 at 16:17
1

Do not return a 404 error code, return null

As you have found out, the http return codes are for use by the http protocol layer, not your application layer. Return a 200 and null content, or throw an exception and return 500 if the device id is not found.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.