Is it bad practice to create a resource in a GET request when the resource will be created later automatically?

Question

At the moment I design a RESTful API for a resource that is normally created by a cron job from existing data.

Since the cron job runs only every 10 minutes it is possible that GET: /user/{id}/resource returns a 404 Not Found. In that case the client needs to create the resource with a POST request with an empty body I think.

To make things more convenient I would like to create the resource when the client calls GET: /user/{id}/resource if it is not existent and return the freshly created resource.

Are there arguments against using GET to create the resource that later will be created automatically anyways?

Some more information on why the cron job is needed:
The resource is also consumed by another service. This service calls a route GET: /users/usersWithResource to sync users to its database.

Answer 1

The strongest argument would be that it violates HTTP Semantics.

GET is a safe method, and safe methods are "essentially read-only". That doesn't mean that there can't be side-effects. Two examples are given in the RFC. One is appending to a log file, even though append operations could cause the server to fail if it is out of storage space. Another example is charging an account when an advertisement is displayed. However, these examples are not state changes on the target resource, and the use of a safe method means that "the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource".

Creating a new resource would be unexpected behavior, to both clients and future maintainers of the system. Most clients or people developing clients would not expect server state changes on a GET request, and people maintaining the system may not expect to find such behavior implemented as a response to a GET request. It would be surprising behavior to many people. I tend to avoid surprising behavior due to the communication (between people about the behavior) and maintenance (when debugging or evolving the system) overhead.

That said, I have seen systems that do implement behavior that you describe, so it's not unheard of. However, there's not enough information to say if it makes sense in your context. I would need to understand why it is beneficial to create the resource in response to a GET request instead of allowing GET to return the current state of the server and the cron job to perform its job of creating necessary resources. The benefits could very well outweigh the costs.

Answer 2

To make things more convenient I would like to create the resource when the client calls GET: /user/{id}/resource if it is not existent and return the freshly created resource.

That's fine.

The semantics of a GET request are "transfer the current selected representation for the target resource". How the server produces that representation is an implementation detail (which is not constrained by HTTP semantics).

See also: Fielding, 2002.

Answer 3

There is a security consideration here with creating data using a GET request. Semantics aside, a simple script tag on any site on the Internet could potentially carry out a DDOS attack.

<script src="https://yoursite.com/user/1/resource" defer></script>
<!-- 9,998 more of these tags -->
<script src="https://yoursite.com/user/10000/resource" defer></script>

The browser will happily send that GET request with cookies (unless you enforce CORS restrictions on those cookies).

Now imagine user IDs are sequential numbers, and there are 10,000 of these script tags on one page where the user Id begins with 1 and is increased by one on each subsequent tag. The browser will fire off a whole bunch of these requests at once. Not an issue if the person visiting that page is unauthenticated, but what happens if a user who is logged in visits this page?

This, of course, depends on how authentication is handled in your application. If using bearer tokens in the http headers, then this isn't likely an issue. User IDs which are not numbers would also mitigate this situation providing your code handles the use case where an non-existent user Id is specified in the URL. If your site uses cookie-based authentication and you don't have cookies properly restricted by domain, then blammo. Your site could get pretty busy.

In a way, I wish I could combine my answer with the one from Thomas Owens. My answer illustrates why a GET which does more than "read" information can be problematic. Sometimes the semantics of REST don't give you the full picture, and you must consider the ramifications of malicious users abusing your system to fully understand why a particular recommendation exists.

I would recommend returning a 404 Not Found and forcing the client to issue a POST to create the resource.

Conversely, if you can mitigate scenarios like the one I outlined above, then the answer by TheVoiceOfUnreason applies. You could create the resource automatically and accept that this might be surprising.

Sometimes you have a compelling reason to break or stretch semantics if it makes sense for the use case, you properly document this deviation from client expectations, and you can mitigate any cyber security issues that arise from misuse.