Re: Bookmark 'stability'

Paul Cohen wrote:
> 
> 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.
> 

No, it isn't.  Does the system work with the new URLs?  Then it isn't
dependent on the old ones.  Are they supported for user convenience?
That would be the server controlling its 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.
> 

OMG, standardized media types are a key concept of REST, time to read
the thesis again.  The whole point of "visibility" is the re-use of
standardized protocol elements, i.e. registered headers and media types.
Using an unregistered media type is not visible, therefore it induces
tight coupling between client and server.  HTML is ubiquitous and
standardized, making it visible, so a server using it is not tightly
coupled to anything, but rather, is loosely coupled to any and all web
browsers.

> 
> 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.
> 

Client requests old URL.  Server responds 308 with new URL.  Client
updates bookmark, never requests obsolete URL again.  There is no
coupling here, by any definition of the term.

-Eric