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

Review status: all files reviewed at latest revision, 15 unresolved discussions.

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 1 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcUoXZ9CSirPrVMr3o:-Kxd6ulA3mJG7j7GK4eP:bhefnc5) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L1)):*
<details><summary><i>Previously, lanthaler (Markus Lanthaler) wrote…</i></summary><blockquote>

Why do you call it "indirectly"? What's indirect about it?
</blockquote></details>

Good point. Actually now that I think of it, it's really the opposite: event is created directly (rather then by posting it to the collection).

Or should I just call this "Creating with PUT" and not be fancy?

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 6 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcUwM4IbV44gBrIv6X:-Kxd6VH9B9g79oalpxew:b-896fix) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L6)):*
<details><summary><i>Previously, lanthaler (Markus Lanthaler) wrote…</i></summary><blockquote>

`event's identifier` -> event identifiers?
</blockquote></details>

Done.

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 7 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcV-ElopVA4z9XGxI0:-Kxd6bzTl59CTnSc23jm:bh5v2sb) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L7)):*
<details><summary><i>Previously, lanthaler (Markus Lanthaler) wrote…</i></summary><blockquote>

control what? The identifier? The URL?
</blockquote></details>

I guess I wasn't sure myself and forgot about it. **The URL** sounds good?

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 10 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcV7lBobudR-WyuFut:-Kxd6p1JFweEq-tfEQOY:b-hz1bsj) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L10)):*
<details><summary><i>Previously, lanthaler (Markus Lanthaler) wrote…</i></summary><blockquote>

... controlling parts of the URL (I think that's the point here, isn't it)?
</blockquote></details>

Yes, part of. It's that and actually using doing PUT to the new resource itself. After all the server could link to concrete resource to PUT. Such as by minting a different URL for every GET. This is actually a good practice because let's the client take advantage of idempotency.

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 34 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxZXSL5Owpv1cqTG5AR:-Kxd7nGImf6tz3AJP6Bu:bfu3j6l) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L34)):*
<details><summary><i>Previously, lanthaler (Markus Lanthaler) wrote…</i></summary><blockquote>

Hmm... that recursive parameter seems to open a can of worms. When should a client stop searching for the operation? It's easy to come up with an example that would crawl all of Wiki-/DBpedia
</blockquote></details>

Well, it would only traverse the representation. Not go over the wire and dereference resources.

But your point is still valid, but, what would you propose as alternative?

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 36 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxZY9gJ8iisuB-N2HfY:-Kxd7wpCLKaGcGOPga_V:b-w6jgyp) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L36)):*
<details><summary><i>Previously, lanthaler (Markus Lanthaler) wrote…</i></summary><blockquote>

An alternative that might be cleaner would be to first resolve the target of the operation to transform an abstract operation into a concrete one. [Expand is the name the URL Template spec uses for that process](https://tools.ietf.org/html/rfc6570#section-3).

```js
operation.expandTarget(templateVariables);
client.invoke(operation, event);
```
</blockquote></details>

I like that. Only I would make this more functional instead of mutating the operation

``` js
const operationTargetExpanded = operation.expandTarget(templateVariables);
client.invoke(operationTargetExpanded, event);
```

---

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

In one of the issues, we discussed that server could provide to client concrete IRI for new resource, so the resource doesn't exist yet and GET on that IRI provided by the server would result in 404 https://github.com/HydraCG/Specifications/issues/134#issuecomment-335028831
</blockquote></details>

As an example think of a discussion thread where the server offers random URIs for replies. This way the client can safely PUT multiple times without actually posting multiple comments.

So like @elf-pavlik says, if a resource doesn't exist yet is the client technically replacing or creating it? I think it's still creating. You can create resources but there is no representation.

I rephrased this sentence by the way.

---

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

What are the semantics that you want to express here? Can the client expect the created resource to be added to the collection? In other words, what's the relationship of the collection to the IriTemplate and the Operation? If the resource will become a member, something like a `hydra:memberTemplate` might be preferable (see also https://github.com/HydraCG/Specifications/issues/16)
</blockquote></details>

`hydra:memberTemplate` almost works but again, the object of this property doesn't have to be an `IriTemplate` at all.

@elf-pavlik here's an example:

1. You register on a website
1. The server creates a private profile for you, say, `/user/some-guid`
1. You get a link to `/user/{public-user-name}` (or `/user/some-guid/public` if it wasn't to be a template)
1. You `PUT` to that resource to create a publicly visible profile resource

So you link to a resource which doesn't initially exist and it's not part of any collection. But the general structure of your hypermedia is the same. I think that Stack Overflow follows a similar pattern.

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 72 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxchCDgCDQQ4nzkMnf4:-KxdDD7WRutDpgYGwZxB:b81xjrp) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L72)):*
<details><summary><i>Previously, lanthaler (Markus Lanthaler) wrote…</i></summary><blockquote>

This is a datatype, not a property. It should be something like `schema:name` or `example:slug`
</blockquote></details>

Of course, my bad.

And what if `property` was removed from a template mapping? Is that legal?

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 97 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxciNXcDOyiU5-EUn3l:-KxdDRGnqVvAdXI6feoh:bw1q44r) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L97)):*
<details><summary><i>Previously, lanthaler (Markus Lanthaler) wrote…</i></summary><blockquote>

This is problematic. What is this URL relative to? How should the server receiving it interpret it (and thus the rest of the document)?
</blockquote></details>

I actually copied this from UC5 and probably similar in other use cases. Let's discuss separately? @alien-mcl?

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 124 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcjZT6dVJharDWu_oJ:-KxdDgoMzoayjZm5GA_7:bw4auty) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L124)):*
<details><summary><i>Previously, lanthaler (Markus Lanthaler) wrote…</i></summary><blockquote>

So, why is it then associated to the Collection at all?
</blockquote></details>

I'm just saying that there isn't enough information to go on until we come up with more meta data for operations. We also haven't defined any concrete semantics here AFAIK and thus the client cannot assume anything which is not explicitly stated in the above representation.

---


*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-340280645 using your GitHub account

Received on Sunday, 29 October 2017 17:51:49 UTC