A web application is not complete without an API nowadays. APIs allow third parties - or just end users - to use the data from the platform for whatever they want. But by allowing applications to make automated calls to your API can result quickly in our systems overloading. Too many times third party applications will be polling your API when they don’t really need too, and maybe you can lighten the load a bit with some heavy-duty caching, but in essence you want that every API call made matters.
During a presentation I gave yesterday about REST, there was a discussion about redirection (more detailed, a redirection from a queue to the actual resource during asynchronous operations). During this presentation (and blog-post), I’m using a 303 HTTP status code to indicate that the operation has been completed and that the created resource can be found at another URI. So in essence, it makes sense to use a 303. At least to me, and quite possibly the rest of the world too.. But this triggered a side-discussion on which HTTP status code to use, and the more I think about it, the more complex it believe this problem actually is.