How should client of Restful API handle http status 301 redirect upon POST?

Question

Question

How should a well-designed application handle 301 "moved permanently" redirects upon http POST to restful api?

Context

• Our hosted application offers a restful api
• We have a customer extensively who uses our restful api in their own 'on-premise' application [fwiw, installed at dozens of sites-- with no easy way to update]

• We are migrating our application to a new data centers and in the process we will switch them (and others) from 'plain text http' to 'ssl-encrypted https'. [The physical location data center of course is irrelevant, but the new data center has more stringent security rules and thus mandates https]

• Our front end (haproxy/nginx) will send a 301 'Moved Permanently'

• This 301 redirect preserves query parameters but loses post data

I know that "restful api's should be permanent", but, merde arrive (that's shit happens in French)--Empires crumble, Berlin Wall falls, Oracle buys Sun etc.

The Problem

Their application makes HTTP post calls to our restful api. When the front end returns 'http status 301', their application does not 're-post' to the new url, and the update fails.

Questions

• How should error handling handle 301's as well as other http statuses? ( pseudocode will suffice)
• Should our 'front end' do something different for '301'?

Answer 1

To fulfill your "well-designed" requirement in the sense of "pure RESTfulness", the client should re-send the request to the new URI. A response code of 301 indicate the resource has moved, and cannot be used to fulfill the request, so there's really no fallback position.

If the client attempts to re-post, but loses data, that's a client bug. The "correct" behavior of a client varies by your requirements: it could treat the redirect as a recoverable error case, and repost transparently; it could repost while instructing the user to update the endpoint; or it could fail with an appropriate error message.