Re: Bookmark 'stability'

Paul Cohen wrote:
> On Sun, Oct 7, 2012 at 6:22 PM, Eric J. Bowman <[email protected]> wrote:
>> 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.

It's Representational State Transfer, you transfer the state of a 
resource through a representation of it. The entire thing is hinged on 
transferring representations of state via well defined data types, 
from/to URI accessible resources using standardized protocol elements. 
This is what makes REST loosely coupled, and suitable for internet/web 
scale usage.

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

Can be summed up as "cool URIs don't change".

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

Is the concept of a "server API" useful? I mean REST is an information 
hiding protocol, for any potential URI you can interact with, you have 
no idea if there are one or ten-thousand servers behind it, it's of no 
concern. You can build a RESTful service over thousands of different 
URIs, with different domain parts, on different machines around the 
world using different languages, operating systems, ones you control and 
ones you don't, and each resource itself be a computation over hundreds 
of other disparate data sources, etc. Each part of the service, each 
resource, can be independently reused in unexpected ways.

What's the point of having a massively scalable loosely coupled 
architectural style and supporting protocols + media types, if you're 
going to centralize and tightly couple everything, and require clients 
to have prior knowledge which can only be gained out of band?

If a URI is GETable, then it would make sense and be good practise to 
ensure it's GETable more than once, and on the rare occasions where 
there's a requirement for it to expire, provide a half decent 
explanation in response to any request to indicate what's happened, 
either as MRD, HRD, or both along with appropriate status codes. Seems 
like common sense?