An HTTP 200 Does Not Mean the Operation Succeeded

Mon, 01 Jan 2018 00:00:00 +0000

Two requests reach the same JSON application.

The first lacks authentication. The server returns HTTP 200 with this body:

{
 "status": 0,
 "error": {
 "code": 401,
 "message": "Unauthenticated"
 }
}

The second is authenticated but lacks permission to browse a collection. It also returns HTTP 200, this time with an empty array:

[]

Regression tests pin both behaviors. Neither can be interpreted from the status code alone, and the empty array is worse: it is indistinguishable from an authorized search which genuinely found nothing.

A Timeout Is Part of the Contract

Fri, 01 Jul 2016 00:00:00 +0000

One accounting integration went down often enough that we stopped being surprised by it. Sometimes it came back with an expired TLS certificate. A different provider scheduled maintenance during our peak operating hours. Neither system became more reliable just because our code was willing to wait.

Waiting longer was not resilience. It turned someone else’s outage into our capacity problem while leaving the caller with the same unanswered question:

How long may this attempt wait before its result is no longer useful?

That answer belongs to the operation, not the HTTP library. If we leave it to a library default, a transport setting decides how much of the customer’s time and our worker capacity one dependency may consume.

Http on Brian Faust

An HTTP 200 Does Not Mean the Operation Succeeded

A Timeout Is Part of the Contract