[Geoserver-devel] more rest configuration api feedback, uri construction

Justin_Deoliveira · February 9, 2009, 6:15pm

Continuing on from my last thread. From teh same thread on geo-web-rest Haris, the developer who is building the mapguide rest api, brought up another good issue, related to the last thread.

The issue is that our current representations of objects are missing links making it easy for the client to "drill down". As an example, consider the xml representation of a workspace:

There is no links pointing the client at any of the datastores contained in the workspace. This again relies on existing knowledge in the client to have to construct the proper uri to request the datastores for this workspace.

The solution is to use a link. So the above would look like:

I am not sure i have nailed the semantics of "alternate" correctly, but that would be the general idea.

Thoughts?

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Andrea_Aime3 · February 9, 2009, 6:21pm

Justin Deoliveira ha scritto:

Continuing on from my last thread. From teh same thread on geo-web-rest Haris, the developer who is building the mapguide rest api, brought up another good issue, related to the last thread.

The issue is that our current representations of objects are missing links making it easy for the client to "drill down". As an example, consider the xml representation of a workspace:

<workspace>
   <name>foo</name>
    ...
</workspace>

There is no links pointing the client at any of the datastores contained in the workspace. This again relies on existing knowledge in the client to have to construct the proper uri to request the datastores for this workspace.

The solution is to use a link. So the above would look like:

<workspace>
   <name>foo</name>
   ...
   <dataStores>
     <atom:link rel="alternate" href=".../workspaces/foo/datastores"/>
   </dataStores>
</workspace>

I am not sure i have nailed the semantics of "alternate" correctly, but that would be the general idea.

Looks good to me... what is atom:link thought?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · February 9, 2009, 6:40pm

Looks good to me... what is atom:link thought?
Cheers
Andrea

Its the construct used by atom for linking. Most commonly seen in feed entries to link to the actual source of an entry. This stuff is new to me... I am sure somone else can give you a much better answer :).

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

David_Winslow · February 12, 2009, 10:26pm

On Mon, 2009-02-09 at 11:15 -0700, Justin Deoliveira wrote:

Continuing on from my last thread. From teh same thread on geo-web-rest
Haris, the developer who is building the mapguide rest api, brought up
another good issue, related to the last thread.

The issue is that our current representations of objects are missing
links making it easy for the client to "drill down". As an example,
consider the xml representation of a workspace:

<workspace>
   <name>foo</name>
    ...
</workspace>

There is no links pointing the client at any of the datastores contained
in the workspace. This again relies on existing knowledge in the client
to have to construct the proper uri to request the datastores for this
workspace.

The solution is to use a link. So the above would look like:

<workspace>
   <name>foo</name>
   ...
   <dataStores>
     <atom:link rel="alternate" href=".../workspaces/foo/datastores"/>
   </dataStores>
</workspace>

I am not sure i have nailed the semantics of "alternate" correctly, but
that would be the general idea.

Thoughts?

-Justin

From the AtomPub spec: (http://atompub.org/rfc4287.html#element.link)

The "atom:link" element defines a reference from an entry or feed to a
Web resource. This specification assigns no meaning to the content (if
any) of this element.
...
The [rel] value "alternate" signifies that the IRI in the value of the
href attribute identifies an alternate version of the resource described
by the containing element.

So this seems like a pretty valid use. However, it is XML-specific, so
how do we carry it over to JSON and other non-xml formats? The solution
I've seen is to have the value itself be a relative link to the
resource's URI. That is, any representation of something that contains
or otherwise references other resources should represent them as URL's.

So instead of
<dataStores>
<atom:link rel='alternate' href='.../whatever'>
</dataStores>

we have
<dataStores>
<store href='.../whatever'/>
</dataStores>

or perhaps we could use atom:links for this as well; I don't see
anything appropriate in the document I linked above, but we could use
<store><link rel='self'/></store>

--
David Winslow
OpenGeo - http://opengeo.org/