Repository navigation
An idea for URL Fragments #16
Description
Activity
@sheavalentine-mdsol Makes sense till:
and again you can subselect http://some.hale.doc/resource#self/href
What would be a reason to subselect the
hrefof a link?I don't know that there's a /good/ reason, but it makes the interpretation of fragments generic.
I've argued in email that if you've written your profile such that you expect to get a fragment request, you've written your profile wrong. If an attribute could reasonably be used as a profile in itself, it should be its own profile. Otherwise we risk the absurdity of having all references to the
buttontype have a profile living at/betamax_player#button.Right now you can serve HALE docs from pastebin if you want, do we really want to lose that?
I should clarify.
I would assume that a fragment is a client directive. So, a url fragment can point to a particular part of a resource. The service would ignore the fragment - I'm just suggesting the client has a non-ambiguous way of understanding what is bing pointed to.Ah, okay, cool. I'm still not sold on this being anything other than an antipattern, though: now we have clients downloading the giant
betamax_playerprofile in order to get thebuttonprofile.But maybe it's inevitable and maybe we should have standards for it.
Do you see this as a step toward telling clients in meta how access elements of resources, e.g. to build selectors?
Okay, so here's the usecase:
I am an application hosting Diagnostic Repair Drones. One of the things that relates to my resource is "docking station".
A "docking station" exists as an element in a Leviathan resource, but the service hosting Leviathans is completely uncontrolled by me.
Thus, I want to be able to say"_links" { "docks_at" {"href": "http://farscape.services.com/leviathan/1735962#dock1 }
So when a client gets my DRD resource, it can understand that the "docks_at" relationship references a specific element of the Leviathan resource. Thus the client, when semantically binding 'docks_at' can dereference the specific fragment being pointed to.
"Do you see this as a step toward telling clients in meta how access elements of resources, e.g. to build selectors?"
That certainly would be one use.
So, if a service is serving a Hale document, and a client requests a fragment, there is a sound and consistent way we could handle that (or that the client could handle it).
If an attribute matches the first part (divided by slashes) of a fragment it gets the attribute:
http://some.hale.doc/resource#attr1 returns
"foo"http://some.hale.doc/resource#attr2 returns
{"sub1": "ninja", "sub2": "cow"}You can also subselect
http://some.hale.doc/resource#attr2/sub1
"ninja"If no attribute matches, check embedded:
http://some.hale.doc/resource#items
[{"_links": {"self": {"href": "some.hale.doc/resource/id1"}}}]otherwise try and match a link
http://some.hale.doc/resource#self
{"href": "http://some.hale.doc/resource"}and again you can subselect
http://some.hale.doc/resource#self/href
"http://some.hale.doc/resource"(Obviously this is just some thoughts...)