HTTP SubStatus codes in micro services

I have been working with enterprises who embrace micro services architecture than monolithic applications.

While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.”- Martin Fowler.

Most of the micro services architecture which i have worked with mostly involve in developing services using REST where they heavily rely on HTTP status codes for communicating status back to the caller.

Are HTTP status codes really sufficient to communicate correct status code back to client? For example lets take 403, Service  may return a 403 Forbidden HTTP Status code in response to a request from a client for a web page or resource to indicate that the server can be reached and understood the request, but refuses to take any further action. Status code 403 responses are the result of the service being configured to deny access, for some reason, to the requested resource by the client.

A 403 response generally indicates one of two conditions:

• Authentication was provided, but the authenticated user is not permitted to perform the requested operation.
• The operation is forbidden to all users. For example, requests for a directory listing return code 403 when directory listing has been disabled.

Well HTTP status code 403 can tell that resource is forbidden but never the reason why it is forbidden. There could be several reasons why the particular resource is forbidden for example lets assume that i am trying to read an order owe2314 accessing an order REST endpoint using the following URL.

http://domain.com/orders/owe2314

A client got an 403 forbidden error and it is forbidden for one of the following reasons, just listed few but there are many more reasons why the client could be seeing 403 forbidden error. 

1. Access is denied.
2. Read access is denied for user.
3. SSL is required to view this resource, i can only access order resource using SSL/HTTPS. 

Well how will i send this extra information back to the client so that client will have more information to take any further action.

There are different ways to do this one way is to just send the HTTP status code and also send some error description back in the message body which would look like some thing below.

{
     "errors": [

           {
                   "type": "FORBIDDEN",
                   "message": "SSL is required to view this resource."
           }
                   ]
}

If client is interested more about the forbidden error they can read the message and try to get the more information why it is forbidden.

I have seen one more interesting way of doing this through HTTP sub status codes which seems to be a standard way if you are using Internet Information Services (IIS) of Microsoft. This is how it looks like we would have 403.x where x is the sub status code. It would look like following.

1. Access is denied. [ 400.1 ]
2. Read access is denied for user. [ 400.2 ]
3. SSL is required to view this resource, i can only access order resource using SSL/HTTPS. [ 400.3 ]

I have never used this kind of sub status just wanted to share this may be it makes sense to have these sub status codes. Seems like though these are not officially supported by IANA  some of the organizations are using these status codes.

Let me know your thoughts on this HTTP sub status codes and what do you think of using these.