Re: Bookmark 'stability'

On Sun, Oct 7, 2012 at 6:22 PM, Eric J. Bowman <[email protected]> wrote:
> Paul Cohen wrote:
> >
> > I mean that *forcing* a server to commit itself to maintaining URI:s
> > is coupling.
> >
>
> Maintaining obsolete URIs is not an example of "coupling" as applies to
> REST.

I mean coupling in the sense of dependencies. Dependencies that lead
to developers having to implement code in the server to maintain
URI:s. As Steve Klabnik pointed out: It is an incredibly clear
violation of servers controlling their own namespace.

> REST isn't "decoupled" but rather, "loosely coupled" around
> standardized data types. The more obscure the data type, the tighter
> the coupling.

My understanding of coupling in the context of data types is quite the
opposite! Also I don't see that REST deals with data types at all -
standardized or not.

> The more ubiquitous the data type, the looser the
> coupling. What's being discussed is the degree of coupling between
> client and server, not server and Web Developer. It gets very confusing
> when participants in a discussion introduce their own definitions of
> terms.

I don't think you understood what I meant. I used the term "coupling"
in the sense that this client requirement on the server (of
maintaining URI:s) leads to undesired consequences for the developers
and the server.

As for the definition of coupling, a decent discussion on the term
"coupling" and different aspects of coupling with regards to REST and
web can be found here:

  https://wiki.kuali.org/download/attachments/140968166/LooseCoupling.pdf

The original thread began with Jan Algermissens question "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?"

I think that all URI:s returned by a server should be considered
bookmarkable by clients! However, this being the distributed web,
clients should not make any assumptions on those URI:s being valid for
all time (amen), but instead be prepared for getting a redirect or
even a 404 next time they dereference the URI. A polite server will of
course redirect if possible but is not *required* to do so.

Ideally a server API has only one entry point URI, but for practical
purposes I think it is reasonable in many cases to have a set of entry
URI:s. Actually this set of URI:s could just as well be considered a
set of different server API:s! These URI:s can be differentiated
simply by virtue of them being published as "official" entry URI:s.

/Paul

--
Paul Cohen
www.seibostudios.se
mobile: +46 730 787 035
e-mail: [email protected]