Question

Let’s assume we have a client/server interaction happening over unreliable network (packet drop). A client is calling server’s RESTful api (over http over tcp):

• issuing a POST to http://server.com/products
• server is creating an object of “product” resource (persists it to a database, etc)
• server is returning 201 Created with a Location header of “http://server.com/products/12345“
• ! TCP packet containing an http response gets dropped and eventually this leads to a tcp connection reset

I see the following problem: the client will never get an ID of a newly created resource yet the server will have a resource created.

Questions: Is this application level behavior or should framework take care of that? How should a web framework (and Rails in particular) handle a situation like that? Are there any articles/whitepapers on REST for this topic?

Answer 1

If it isn’t reasonable for duplicate resources to be created (e.g. products with identical titles, descriptions, etc.), then unique identifiers can be generated on the server which can be tracked against created resources to prevent duplicate requests from being processed. Unlike Darrel’s suggestion of generating unique IDs on the client, this would also prevent separate users from creating duplicate resources (which you may or may not find desirable). Clients will be able to distinguish between “created” responses and “duplicate” responses by their response codes (201 and 303 respectively, in my example below).

Pseudocode for generating such an identifier — in this case, a hash of a canonical representation of the request:

func product_POST
    // the canonical representation need not contain every field in
    // the request, just those which contribute to its "identity"
    tags = join sorted request.tags
    canonical = join [request.name, request.maker, tags, request.desc]
    id = hash canonical

    if id in products
        http303 products[id]
    else
        products[id] = create_product_from request
        http201 products[id]
    end
end

This ID may or may not be part of the created resources’ URIs. Personally, I’d be inclined to track them separately — at the cost of an extra lookup table — if the URIs were going to be exposed to users, as hashes tend to be ugly and difficult for humans to remember.

In many cases, it also makes sense to “expire” these unique hashes after some time. For example, if you were to make a money transfer API, a user transferring the same amount of money to the same person a few minutes apart probably indicates that the client never received the “success” response. If a user transfers the same amount of money to the same person once a month, on the other hand, they’re probably paying their rent. 😉