Re: [Specifications] CreateAction with HTTP PUT

I've spent some time thinking about it. I've ended up with a conclusion that creating a resource is one thing, linking it with another resource (i.e. collection to be specific) is another matter.

Regardless the approach (rich command/action vocabulary or rich relations vocabulary), creating a resource may with POST, but may not end up with adding newly created resource to the collection.
This is how POST works - we send a resource for processing, but we don't really know on what will happen.
Situation with PUT is a bit better - hierarchy of resources expressed with segments in the resource's URL may imply that the putted resource will be added to the collection - stil it's not a mandatory behavior. Anyway, what if we want to add to the collection a resource of which URL is not related to the target collection in any way (i.e. URL of a person we want to add as a friend)?

Finally, I've ended up with something like this:
```
0. Begin
1. Do I know the IRI of the resource I create?
   If yes, go to 4, otherwise go to 2.
2. Is there a POST operation available?
   If yes, go to 3, otherwise go to 7.
3. POST new resource to the operation pointed URL.
   Obtain a Location header and assigned it to the resource's IRI.
   Go to 6.
---
4. Is there a PUT operation available?
   If yes, go to 5, otherwise go to 7.
5. Assign the URL I create to the resource's IRI and PUT the resource to that URL.
---
6. LINK the resource to the designated target resource (i.e. a collection)
   using a desired relation.
   Type of the relation "describing" semantically as a collection concluding
   is a subject for discussion.
7. Abort, unable to perform action.
8. End
```

Steps 1-3 are related to creating a resource if we don't know on how to create IRI of the resource being created.
Steps 4-5 are related to creating a resource assuming we know on how to created the IRI mentioned.
Step 6 is actually an operation that "adds" newly created resource to the collection - this is the only operation that should make the client sure of what will happen.
Please not that only step 2 (which may be treated as a fallback for dumb clients) is not idempotent.
What do you think about that?

-- 
GitHub Notification of comment by alien-mcl
Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/141#issuecomment-333970341 using your GitHub account

Received on Tuesday, 3 October 2017 20:36:09 UTC