Re: Appropriate use of HTTP status codes for application health checks

[Matthew Kerwin <[e-mail]>]

Hi Matt,

On 23 February 2017 at 10:54, matt <[e-mail]> wrote:

> Hello,
>
> My colleagues and I are involved in a debate about the proper usage of
> HTTP return codes for application health pages.
>
> For instance, you have a /health page that returns JSON listing your
> application’s dependencies as either “Up” or “Down”
>
> Some suggest that it is acceptable for your /health page to return an
> unassigned 5xx or 503 if the /health page returns successfully, but the
> page results indicate the application is not healthy. Spring Boot
> <https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-1.1-Release-Notes#healthindicators> has
> done this. Although I have reservations about 503 since your request for
> the page was handled successfully.
>
> Other contend that your /health page should *always* return a 200
> regardless of whether the page results is indicative of application health
> or not.
>
> As a layman I can see the argument for both sides, and it seems both
> practices have been used in the past. I perused the RFCs but I don’t feel
> like I found the ‘silver bullet’ answer on this.
>
> Kindly,
>
> Matt
>

The trick with REST (assuming that's what you're going for here) is
defining the resources.

If the resource is a status page, then it can return 200 to say that
the *status
*is available, even if the available status is "unavailable".

If the resource is the dependency itself (or a model or representation
thereof), it can return a 5xx or whatever to say that the *dependency* is
unavailable.

In general, I say: do what feels right, and document it clearly.

Of course, I'm the biggest REST expert on this list, so I'm 100% correct.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/