| Newsgroups |
gmane.comp.web.services.rest |
| Message-ID |
<[email protected]> |
I see that nobody mentions link relations.
http://www.w3.org/TR/html5/links.html#link-type-bookmark defines the "bookmark" relation.
Indeed, the server cannot control whether a URI is bookmarked or not, but it should definitely advertise its capabilities. In this case, the capability of maintaining a URI as an entry point for resource X "forever".
The only resource that has the bookmark contract from the start is the API's entry point (root). For the rest, may them be of type bookmark or not, the client needs to know the freedoms and responsibilities it has for bookmarking them.
The whole idea of a REST API is to reduce coupling. Why create unnecessary URI coupling?
--- In [email protected], Jan Algermissen <jan.algermissen@...> wrote:
>
> Hi,
>
> one of the obligations a server has in a RESTful system (IMHO
> anyway) is to keep those URIs stable that make good bookmarks.
> (as in "Cool URIs don't change"). [1]
>
> Some questions keep bugging me:
>
> - Should all URIs a server makes known to clients be considered
> possible bookmarks?
> If not, how do I differentiate between those that are and those
> that are not?
>
> - Given that the applications executed by the clients are not known to
> the server, how can the server possibly know what the steady
> states of all those applications are? And hence, what URIs the
> clients might consider to be bookmarks?
>
> Or is it as simple as
>
> "Bookmarks are resource identifiers from a prior interaction.
> They are bread-crumbs. Sometimes they get eaten." :-) [2]
>
> Jan
>
>
> [1] And I find it particularly interesting that in this aspect REST is (implicitly) constraining *over time*. Which no other style does, AFAIK.
> [2] http://tech.groups.yahoo.com/group/rest-discuss/message/13606
>