REST status code and eventual consistency?

Question

I have a RESTful web service that runs on the Google App Engine, and uses JPA to store entities in the GAE Data Store.

New entities are created using a POST request (as the server will generate the entity ID).

However, I am uncertain as to the best status code to return, as the GAE DS is eventual consistent. I have considered the following:

• 200 OK: RFC states that the response body should contain “an entity describing or containing the result of the action”. This is achievable as the entity is updated with it's generated ID when it is persisted to the DS, therefore it is possible to serialize and return the updated entity straight away. However, subsequent GET requests for that entity by ID may fail as all nodes may not yet have reached consistency (this has been observed as a real world problem for my client application).
• 201 Created: As above, returning a URI for the new entity may cause the client problems if consistency has not yet been reached.
• 202 Accepted: Would eliminate the problems discussed above, but would not be able to inform the client of the ID of the new entity.

What would be considered best practice in this scenario?

Answer 1

A get by key will always be consistent, so a 200 response would be Ok based on your criteria unless there is a problem in google land. Are you certain you observed problems are from gets rather than queries. There is a difference between a query selecting a KEY vs a GET by key.

For a query to be consistent it must be an ancestor query, alternately a GET is consistent, anything else may see inconsistent data as indexes have yet to be updated.

This is all assuming there isn't an actual problem in google land. We have seen problems in the past, where datacenters where late replicating, and eventual consistancy was very late, sometimes even hours.

But you have no way of knowing that, so you either have to assume all is OK, or take an extremely pessimistic approach.

Answer 2

It depends on which JSON REST Protocoll you are using. Just always returning a json Object is not very RESTful.

You should look at some of these:

• jsonapi.org/format/
• http://stateless.co/hal_specification.html
• http://amundsen.com/media-types/collection/

To answer you Question: I would prefer using a format, where the Resource itself is aware of it's URL, so I would use 201 but return also the whole ressource.

The easiest way would be be to use jsonapi with a convenious url schema, so you are able to find a ressource by url because you know the id.