Why would HTTP response code be used in RESTful service to indicate business related logic?

Question

I have read this: What is the appropriate HTTP status code response for a general unsuccessful request (not an error)?

I understand the principles but using HTTP response code to indicate RESTful API service status of a business logic thing seems ambiguous, repetitive and confusing me.

Solely taking about HTTP response code, a 403 may indicates the user not having enough privilege to use the RESTful service, or just don't have right to access the HTTP server (e.g. failed in HTTP authorization ).

So in this case the client should look at the response body to see if it is a business logic error or solely a server error.

For a 404 the client don't know if the resources on the server doesn't exist, or the business object doesn't exist. It has to look into the response body also.

So why would people keep using HTTP response code with business logic error? To me it is more simple to simply look into the response body for a business logic error and handle it. Is there any situation that using HTTP response with a business logic error is necessary?

Many thanks.

Answer 1

So why would people keep using HTTP response code with business logic error?

When creating applications that follow the REST architetural style over the HTTP protocol, you adapt your application domain to resources, which is the central piece of the REST architecture.

The server provide a set of URLs to locate the resources and their state can be manipulated via HTTP verbs and representations such as JSON and/or XML. And HTTP status codes are used to inform the client regarding the status of the operation. A misleading status code will convey wrong information about the status of the request.

The RFC 7231 defines classes of status codes:

• 1xx (Informational): The request was received, continuing process
• 2xx (Successful): The request was successfully received, understood, and accepted
• 3xx (Redirection): Further action needs to be taken in order to complete the request
• 4xx (Client Error): The request contains bad syntax or cannot be fulfilled
• 5xx (Server Error): The server failed to fulfill an apparently valid request

For example, if the request has failed due to a client error (for instance, malformed request or invalid data has been provided in the payload), returning a 2xx or 5xx status code is misleading here. A 4xx status code would be suitable to express what caused the error.

Is there any situation that using HTTP response with a business logic error is necessary?

Some status such as 409 and 422 may be used to represent business logic errors.

To me it is more simple to simply look into the response body for a business logic error and handle it.

It's true that HTTP status codes are sometimes not sufficient to convey enough information about an error to be helpful. But the RFC 7807 was created to fill this gap: it defines simple JSON and XML documents to indicate problems.