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.