support for out-of-line links #17
Comments
This was referenced Dec 10, 2016
|
specifically, the question is how HAL would support the following hypermedia pattern:
|
|
Hi Erik,
Personally I have never experienced the problem you are solving, but I
think this would not conflict with HAL. The linkset representation (in your
example: from B) contain links, yes, but there is no confusion as to how to
interpret the links. I see no problem in making a client understand HAL and
linksets. I see no reason to make it explicitly part of the HAL rfc, though.
Does that make sense?
Best,
Joost
2016-12-16 6:32 GMT+01:00 Erik Wilde <notifications@github.com>:
… specifically, the question is how HAL would support the following
hypermedia pattern:
- a service adds a linkset link to a resource retrieved from URI A
because it does not want to embed all links in the resource representation
right away. the linkset URI points to B and indicates that additional
links for A can be retrieved from B.
- upon requesting/querying links from B, the representation contains
links that have A as their source, because they are supposed to be linking
A and target resources.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#17 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABRDXHfWpuXbNF-VJqmLf-k74QQxVwOks5rIiJhgaJpZM4LJvqP>
.
--
Joost Cassee
+31 (0)6 14585693
https://jcassee.com
|
|
On Dec 16, 2016, at 09:33, Joost Cassee ***@***.***> wrote:
Hi Erik,
Personally I have never experienced the problem you are solving, but I
think this would not conflict with HAL. The linkset representation (in your
example: from B) contain links, yes, but there is no confusion as to how to
interpret the links.
Could you please clarify how the client can determine from the representation obtained from B that the links have A (not B) as their anchor?
I see no problem in making a client understand HAL and
linksets. I see no reason to make it explicitly part of the HAL rfc, though.
Very much agreed. Erik and I are just trying to understand whether HAL could be used for the link server use case. Hence our question as to how one would express in HAL that links have A, not B (the resource that provides the HAL JSON), as their anchor.
Cheers
Herbert
… Does that make sense?
Best,
Joost
2016-12-16 6:32 GMT+01:00 Erik Wilde ***@***.***>:
> specifically, the question is how HAL would support the following
> hypermedia pattern:
>
> - a service adds a linkset link to a resource retrieved from URI A
> because it does not want to embed all links in the resource representation
> right away. the linkset URI points to B and indicates that additional
> links for A can be retrieved from B.
> - upon requesting/querying links from B, the representation contains
> links that have A as their source, because they are supposed to be linking
> A and target resources.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#17 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AABRDXHfWpuXbNF-VJqmLf-k74QQxVwOks5rIiJhgaJpZM4LJvqP>
> .
>
--
Joost Cassee
+31 (0)6 14585693
https://jcassee.com
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
2016-12-16 9:41 GMT+01:00 Herbert Van de Sompel <notifications@github.com>:
On Dec 16, 2016, at 09:33, Joost Cassee ***@***.***> wrote:
> Personally I have never experienced the problem you are solving, but I
> think this would not conflict with HAL. The linkset representation (in
your
> example: from B) contain links, yes, but there is no confusion as to how
to
> interpret the links.
Could you please clarify how the client can determine from the
representation obtained from B that the links have A (not B) as their
anchor?
Sure. The linkset media type is not the HAL media type. So other rules
apply. In particular, the "about" relation define the source of the links.
A client that understands HAL but not linkset will only see the link to the
linkset, of course, but one that understands both will know to add the
links in the linkset (B) to the set of links from the original resource (A).
Best,
Joost
…--
Joost Cassee
+31 (0)6 14585693
https://jcassee.com
|
|
On 2016-12-16 00:52, Joost Cassee wrote:
Sure. The linkset media type is not the HAL media type. So other rules
apply. In particular, the "about" relation define the source of the links.
there is no linkset media type. linkset is a link relation type that
allows to link to a set of links (recursion alert!), but which media
types are used for any of the resources is a different issue.
we are interested to figure out if HAL would be a possible media type
for supporting this scenario, but maybe it is not.
the problem with "about" is the scope: if you assume that "about" sets
the context of *all* links of the context where it appears, then maybe
that's a bit more general than what we want.
continuing from the A/B scenario:
* A is the resource containing a linkset link to B.
* B is supposed to contain links "about" A and does so by using the
"about" link relation.
* B *also* should be able to contain links about B, such as how to page
through a linkset or whatever else interactions there may be concerning
the linkset resource.
so if we accept the assumption that an "about" link in B that links to
"A" sets the context of *all* links in B, then the question is how to
have links in B that actually are about B?
A client that understands HAL but not linkset will only see the link to the
linkset, of course, but one that understands both will know to add the
links in the linkset (B) to the set of links from the original resource (A).
yes, that's the goal. the question is if HAL is capable of representing
this, when it comes to using HAL for representing resource B.
|
|
2016-12-16 18:26 GMT+01:00 Erik Wilde <notifications@github.com>:
On 2016-12-16 00:52, Joost Cassee wrote:
> Sure. The linkset media type is not the HAL media type. So other rules
> apply. In particular, the "about" relation define the source of the
links.
there is no linkset media type. linkset is a link relation type that
allows to link to a set of links (recursion alert!), but which media
types are used for any of the resources is a different issue.
Right, but there is the "application/link-format" media type, right?
Anyway, how about this. Say you document the "linkset" as follows:
"The linkset relation points to a resource containing extra links that
relate this resource to other resources. They should be treated as if they
were links on this resource." (Better worded, but you get the idea.)
If you use the "link-format" media type and want to add links from B as
well, just add them al regular Link headers. Or use HAL for B and document
a profile for linksets. Then put links with source A as its resource state,
and links with source B as its links. Something like:
{
"linkset": {
"rel": { "href": "..." }
},
"_links": {
"rel2": { "href": "..." },
"profile": { "href": "http://some/nice/profile/uri" }
}
}
It makes sense to say that the state/contents of B is the links from A, and
the links from B just be the links from B.
Best,
Joost
…--
Joost Cassee
+31 (0)6 14585693
https://jcassee.com
|
|
On 2016-12-16 14:19, Joost Cassee wrote:
2016-12-16 18:26 GMT+01:00 Erik Wilde ***@***.***>:
> there is no linkset media type. linkset is a link relation type that
> allows to link to a set of links (recursion alert!), but which media
> types are used for any of the resources is a different issue.
Right, but there is the "application/link-format" media type, right?
yes, but that's just one way of serving links, and the "linkset"
relation type (like relation types in general) should be agnostic of the
representation type user for the linked resource.
which is how this got started: i am curious to find out which hypermedia
formats would work well with this idea. maybe HAL isn't one of them, and
that would be interesting to now as well.
Anyway, how about this. Say you document the "linkset" as follows:
"The linkset relation points to a resource containing extra links that
relate this resource to other resources. They should be treated as if they
were links on this resource." (Better worded, but you get the idea.)
that's what @hvdsomp and i are writing up in the draft.
If you use the "link-format" media type and want to add links from B as
well, just add them al regular Link headers. Or use HAL for B and document
a profile for linksets. Then put links with source A as its resource state,
and links with source B as its links. Something like:
{
"linkset": {
"rel": { "href": "..." }
},
"_links": {
"rel2": { "href": "..." },
"profile": { "href": "http://some/nice/profile/uri" }
}
}
this one gets me confused. the way it's planned, "linkset" *is* a link
relation, so there's no need to have a "rel" when you're linking to a
linkset. the "linkset" label *is* the link relation type. the problem is
not how to link to the linkset (HAL can do that by simply using a
"linkset" types link), but how to represent the linkset in HAL (and as
mentioned above, maybe HAL simply cannot do that).
It makes sense to say that the state/contents of B is the links from A, and
the links from B just be the links from B.
now i get it. your idea is to represent the links in B that have A as
their source as a completely different set of links from the regular HAL
links. that's possible, but seems like you'd do all of this outside of
the regular HAL linking model. if that's how it has to be done to get it
to work with HAL, that's interesting.
my though is that for this to work well, the "linkset" object would have
to have a "source" property so that it would make explicit the otherwise
implicit source URI of the links contained in there.
in general hypermedia terminology, these would be "third-party
out-of-line links", but now that i am writing this, it becomes clear to
me that i have to update my hypermedia concepts to better reflect this...
https://github.com/dret/hyperpedia/blob/master/concepts.md#target-identification
…
Best,
Joost
--
Joost Cassee
+31 (0)6 14585693
https://jcassee.com
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#17 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABw1JPS8JvsVH-w-A9OGWWYrFFaG7O44ks5rIw5YgaJpZM4LJvqP>.
--
erik wilde | mailto:erik.wilde@dret.net |
| http://dret.net/netdret |
| http://twitter.com/dret |
|
|
2016-12-17 19:07 GMT+01:00 Erik Wilde <notifications@github.com>:
On 2016-12-16 14:19, Joost Cassee wrote:
> It makes sense to say that the state/contents of B is the links from A,
and
> the links from B just be the links from B.
now i get it. your idea is to represent the links in B that have A as
their source as a completely different set of links from the regular HAL
links. that's possible, but seems like you'd do all of this outside of
the regular HAL linking model. if that's how it has to be done to get it
to work with HAL, that's interesting.
Yes, I thought you were proposing a media type for linksets, but I think
you were suggesting "pulling it up" to a meta level. I actually think using
a media type is pretty elegant. (Especially reusing an existing one,
although the RFC context is a bit weird.) It feels natural that when you
link to a resource's linkset, those links are the state of that linkset
resource.
(I don't "represent HAL", but...) I think HAL basically does two things:
1) Add links, or rather move links from the Link header into the resource
representation.
2) Add caching.
So I do not think there is really much of a "HAL linking model".
my though is that for this to work well, the "linkset" object would have
to have a "source" property so that it would make explicit the otherwise
implicit source URI of the links contained in there.
Yes, I think so too. The "about" relation in your example seemed to match
that purpose, but it could be a property.
in general hypermedia terminology, these would be "third-party
out-of-line links", but now that i am writing this, it becomes clear to
me that i have to update my hypermedia concepts to better reflect this...
https://github.com/dret/hyperpedia/blob/master/concepts.md#target-
identification
Although I think I understand what you mean by that term, but I have never
seen it before.
Best,
Joost
|
|
On Dec 20, 2016, at 10:44, Joost Cassee ***@***.***> wrote:
2016-12-17 19:07 GMT+01:00 Erik Wilde ***@***.***>:
> On 2016-12-16 14:19, Joost Cassee wrote:
> > It makes sense to say that the state/contents of B is the links from A,
> and
> > the links from B just be the links from B.
>
> now i get it. your idea is to represent the links in B that have A as
> their source as a completely different set of links from the regular HAL
> links. that's possible, but seems like you'd do all of this outside of
> the regular HAL linking model. if that's how it has to be done to get it
> to work with HAL, that's interesting.
>
Yes, I thought you were proposing a media type for linksets, but I think
you were suggesting "pulling it up" to a meta level. I actually think using
a media type is pretty elegant. (Especially reusing an existing one,
although the RFC context is a bit weird.) It feels natural that when you
link to a resource's linkset, those links are the state of that linkset
resource.
(I don't "represent HAL", but...) I think HAL basically does two things:
1) Add links, or rather move links from the Link header into the resource
representation.
Links in the Link header can have an "anchor" attribute that overwrites the default anchor, which is the responding resource. That's exactly what @dret and I asked about: could that be done in HAL too ...
Cheers
Herbert
… 2) Add caching.
So I do not think there is really much of a "HAL linking model".
> my though is that for this to work well, the "linkset" object would have
> to have a "source" property so that it would make explicit the otherwise
> implicit source URI of the links contained in there.
>
Yes, I think so too. The "about" relation in your example seemed to match
that purpose, but it could be a property.
> in general hypermedia terminology, these would be "third-party
> out-of-line links", but now that i am writing this, it becomes clear to
> me that i have to update my hypermedia concepts to better reflect this...
>
> https://github.com/dret/hyperpedia/blob/master/concepts.md#target-
> identification
>
Although I think I understand what you mean by that term, but I have never
seen it before.
Best,
Joost
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
2016-12-20 11:17 GMT+01:00 Herbert Van de Sompel <notifications@github.com>:
Links in the Link header can have an "anchor" attribute that overwrites
the default anchor, which is the responding resource. That's exactly what
@dret and I asked about: could that be done in HAL too ...
Ah right. Well, the anchor link parameter (property) is not specified, but
many people (myself included) consider link properties to be an extension
point. Maybe the HAL spec should be more specific on this subject and/or
link to RFC 5988. I have not looked at it closely, but I think the link
properties that HAL does specify follow that RFC.
Best,
Joost
…--
Joost Cassee
+31 (0)6 14585693
https://jcassee.com
|
|
On 2016-12-20 02:26, Joost Cassee wrote:
2016-12-20 11:17 GMT+01:00 Herbert Van de Sompel ***@***.***>:
> Links in the Link header can have an "anchor" attribute that overwrites
> the default anchor, which is the responding resource. That's exactly what
> @dret and I asked about: could that be done in HAL too ...
Ah right. Well, the anchor link parameter (property) is not specified, but
many people (myself included) consider link properties to be an extension
point. Maybe the HAL spec should be more specific on this subject and/or
link to RFC 5988. I have not looked at it closely, but I think the link
properties that HAL does specify follow that RFC.
my concern with adding an "anchor" attribute to HAL as an extension as it
is now is as follows: the "anchor" attribute would change the semantics
of the link, as the link would no longer be from the context to the
target URI, but from the specified anchor. as such, a link using such an
"anchor" extension would be completely misinterpreted by an application
not supporting the "anchor" attribute.
to me, adding the "anchor" would be a non-monotonic extension, breaking
backwards compatibility, and thus could only be done properly in a new
version of HAL that would break compatibility with older ones. in such a
version, "anchor" support would be mandatory, and applications would not
be allowed to ignore it because that would mean misinterpreting the link.
to me, the proposal made by @jcassee earlier is most reasonable: add a
new "_linkset" member that by definition contains out-of-line links. it
could be structured as follows:
{"_linkset": {"http://example.com/A": {"_links": {
"rel1": {"href": "..."},
"rel2": {"href": "..."}
}}}}
meaning that in this case, there would be two links with
http://example.com/A as a source anchor. you could have as many source
anchors as you like, and for each as many links as you like.
i think this works, but this is a complete extension to HAL outside of
HAL's existing linking model, and thus it is not all that interesting to
me. i was trying to figure out if HAL can cover our use case out of the
box, and by now i am fairly certain that it doesn't.
|
|
closing this as it seems that HAL does not support any way to explicitly represent source anchor. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://github.com/dret/I-D/tree/master/linkset-link-rel is something @hvdsomp and i are planning to start pushing as a draft relatively soon. there are different ways to look at it, but one is to think about it as a way to use links as a resource. in the context of HAL, this could be a mechanism of how all/additional links for a resource can be pulled in from a separate resource. for now, i am just wondering if
The text was updated successfully, but these errors were encountered: