REST: How to respond to an HTTP POST
I ran into a problem yesterday. I’d sent a HTTP POST request to a collection of resources on our RESTful web service. Our server responded with an HTTP 201: Created status code and the URI of the new resource in the Location header.
And then… nothing happened.
This was not what I was expecting. I expected my web browser to follow up with a GET request to the URI I’d provided. But Firefox 3 wasn’t biting. A problem with Firefox? I checked in IE8 and Google Chrome and got the same behavior.
Had I misread the HTTP spec? Did I misunderstand the REST pattern? I grabbed for my worn copy of RESTful Web Services. Nope. HTTP 201 seemed to be the right status for this situation.
Had I blundered into some common error? I checked Stefan Tilkov’s useful list of REST Antipatterns. But I couldn’t find anything that quite matched my situation.
I started Googling, but couldn’t find much apart from this question about HTTP Post on Stack Overflow. There were some cryptic responses (to which I’ve added my own answer now).
Eventually, I discovered what I needed to know from Ben Ramsey’s article on HTTP redirection. It’s part of his series discussing RFC 2616, which describes the HTTP/1.1 protocol.
The answer is that while web service clients will often “take the hint” provided by a HTTP 201: Created response, web browsers won’t. If you actually want a web browser to go somewhere else, you need to send a status code in the 3xx series. In this situation, the status code you want is HTTP 303: See Other.
Once I changed the status code returned by the server, all the web browsers followed up the response with a GET to the new URI.
Related Posts
- Using WCF for REST, Part 2
- Using WCF for REST, Part 3
- Using WCF for REST, Part 1
- WCF Bad Request
- Review: Restful Web Services
