Re: [Specifications] Add Use Case: Creating events indirectly (ie. with PUT)

Review status: 0 of 1 files reviewed at latest revision, 5 unresolved discussions, some commit checks failed.

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 58 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxY28Opn5nMlgaMrFGV-r1-58:-KxZT5alxfN3Q4E0FA2n:b-9947ir) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L58)):*
<details><summary><i>Previously, alien-mcl (Karol Szczepański) wrote…</i></summary><blockquote>

I somehow have some doubts about this `manages` construct. What does it say? Are all resources of type `schema:Event` members of this collection? Or should I add each member explicitly? I believe both cases are pretty legal - server could expose on-the-fly views acting as collections just by using some of the resource's attributes (i.e. collection of wines where each resource is of type `foo:Wine`), but it also could expose explicit collections (i.e. my likes that I've added manually).
</blockquote></details>

Interesting points, but I think they are outside of the scope of this PR. Best let's continue this discussion in a new issue or where we discuss the manages block. I merely copied the collection from Use Case 5.

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 64 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxYcL7VkgLlvZsRJlA4:-KxZTNz8LzMGXWkS4PR9:bovmah1) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L64)):*
<details><summary><i>Previously, elf-pavlik (elf Pavlik) wrote…</i></summary><blockquote>

the `manages` block already signals that this collection 'contains' instances of `schema:Event`, and to create we already rely on `schema:CreateAction`, if we take approach similar to `hydra:search` I would prefer to define very generic `hydra:add` which would link to a `hydra:Resource` or 'hydra:IriTemplate`
</blockquote></details>

Sure, I can agree with either. I used an API-specific property here because where I previously minted something in the `hydra` namespace and I thought it caused confusion :).

On the other hand, similar method can be employed to create resource outside the context of collections. I can think of an optional linked resource which can be created once but is not part of any collection. Would you also propose a generic `hydra` term for such uses?

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 78 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxY28Opn5nMlgaMrFGV-r1-78:-KxZUJZ6BZRgvwhMRmAz:bnqbc87) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L78)):*
> that just adds a resource that already exists

I think that's in scope of Use Case 9. Let's discuss there. Here I wanted to add an alternative to creating new resources (see UC 5).

In fact I'll just add in the considerations section a note that this method can be used to create resource outside of a collection context.

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 116 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxYdjO5DKeU7wFvRf8f:-KxZWN1gwDc7qsBtW9vk:bm7n7tr) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L116)):*
<details><summary><i>Previously, elf-pavlik (elf Pavlik) wrote…</i></summary><blockquote>

I would myself include an `@id` even when creating a new resource, since client decides the IRI. To recognize Create vs. Update one should probably do conditional request and use `If-Match` HTTP header https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match

> The `If-Match` HTTP request header makes the request conditional. For GET and HEAD methods, the server will send back the requested resource only if it matches one of the listed ETags. For PUT and other non-safe methods, it will only upload the resource in this case.
</blockquote></details>

Sounds good. @asbjornu, any thoughts about that? You are more knowledgeable in the nuances of HTTP.

---


*Comments from [Reviewable](https://reviewable.io:443/reviews/hydracg/specifications/143)*
<!-- Sent from Reviewable.io -->


-- 
GitHub Notification of comment by tpluscode
Please view or discuss this issue at https://github.com/HydraCG/Specifications/pull/143#issuecomment-340215471 using your GitHub account

Received on Saturday, 28 October 2017 19:49:45 UTC