Posts

Showing posts from 2018

REST API Best Practices: HTTP Status Codes and You, Part 2(xx) - Status 200; Success!

Ah, the HTTP Status Code 200 series. Request sent by client, received by server, understood and processed, and a response has been sent. He shoots he scores, GOALLLLLLLL! The status code 200 series is the "Pass GO, Collect 200 Dollars" of HTTP Responses, this is the result for which we strive. In this part of the series, I will cover some of the major HTTP 200 series response codes and how they can be used as part of an effective REST API strategy. Do note, that I will not cover them all here, but I want to touch on some of the ones you may already know, and some you may not know, but might easily start to use in API development process. So with that, let's start at the very beginning, a very good place to start! HTTP Status Code 200 - OK What it means: Success! Everything worked out. What content to expect returned: This largely depends on your request verb. For example, a GET request might return the requested resource, such as a JSON formatted response. A P

REST API Best Practices: HTTP Status Codes and You, Part 1 - Introduction

How many HTTP Status Codes can you name? We all know a few of the major ones to be sure: 200 - OK, 301 - Moved, 404 - Not Found, 500 - Unavailable... Would you believe me if I told you there were more than 60? You don't have to, check it out for yourself: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes Often when building REST APIs, I have found people defaulting to some of the better known HTTP Status codes - to a fault. Sometimes this is because they are simply updating existing services where the misuse is already coded to duplicate the functionality as part of new REST APIs initiatives, and sometimes it is because they are using codes that work even though there are more specific and better status codes of which they are unaware. An example may be using a 403 Forbidden in place of a 429 for rate limit exceptions. Some services have major aberrations, such as using HTTP Status 200 (Success) to relay everything, even failure messages. While REST APIs may be functional u