GET or PUT for a REST request

Question

I've got a situation where a client app can ask for a resource matching certain criteria, and if a matching resource does not exist it is created and cached. Subsequent requests for the same criteria will return the cached resource.

I could implement this via a PUT request to create the resource and subsequent GETs. However, in my particular scenario that requires the client to know too much about the internal workings of my system i.e. the client shouldn't care whether the resource already exists or not.

So is it ReSTful to allow the client to make a single GET request that happens to create the resource if it doesn't already exist?

Answer 1

Theoretically GET should just GET, and not change the state of your system. See idempotency.

Paragraph from Wikipedia:

Some methods (for example, HEAD, GET, OPTIONS and TRACE) are defined as safe, which means they are intended only for information retrieval and should not change the state of the server.

However, in your scenario an initial GET is setting up a resource purely for caching. Subsequent calls won't change the state of the system, so I'd suggest that GET is fine in this scenario.

Answer 2

Use GET when you are fetching some data and use POST when you are changing some state.

If you use GET to change some state and if your app is over the internet a search engine crawl can have undesired effect on your system.

Also, GET requests are cached by the browser so you can save some bandwidth and server resources in case of data which changes less frequently.

Answer 3

Yes, if the only purpose of creating the resource is to cache it. This way, you can think of your system as already containing all possible GET results and the idempotency is not violated. How the machine gets the result (from cache or by your algorithm) isn't essential and is even uninteresting.

Richard Ev: If you would be so strict, you couldn't even log GET request to your server as logging is a side effect and changes the state of a system. EDIT: I see you are not so strict anymore and I agree :-)

Answer 4

It is absolutely appropriate to use GET for this purpose; the 'rendering' of a resource is outside of the scope of client/server HTTP interaction, so it really doesn't matter whether it is or isn't "created" yet - that is an implementation concern beyond the uniform interface.

What I'm saying is that it doesn't matter to the client - because, as far as it is concerned, the request is safe+idempotent. It doesn't care whether or not the server is creating some content to return on the fly for efficiency reasons, or if it 'already existed' and was simply output.

GET /resource?criteria1=xyz&criteria2=abc