On Dec 4, 2009, at 1:34 AM, Tatu Saloranta wrote:
> On Thu, Dec 3, 2009 at 2:15 PM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>>
> ...
>> A good example of increased coupling was (i dunno if it is now) the
>> OpenSocial API which Roy commented on [1]. IIRC OpenSocial mandated
>> that
>> each implementation use the same URI structure, rather than letting
>> each
>> implementation define their own, with OpenSocial defining the media
>> types
>> and link relationships.
> ...
>
> Not that I know the issue well, but could this be seen more as
> convention-based approach, which actually has its benefits (wrt
> convention-over-configuration)? That is, sometimes it is good to trade
> in flexibility if it can be used to remove required configuration and
> simplifies other aspects of system (in this case reduces amount of
> automatic discovery one has to do).
>
But as a consequence it makes it harder to evolve the server while
remaining compatible with existing clients. For large scale systems
this is very important, especially when things are decentralized as is
the case with the Web.
For a small scale system such looser coupling might not be so
important, as you indicate it is a trade-off. But, I would even argue
that such loose coupling can be important for enterprise systems where
there is often lots of interconnections and moving parts.
That is what i like about REST, it's all about constraining the
architecture and making trade-offs, and you do not have to apply all
the constraints but it is important to understand what consequences
this has in terms of the architecture. In fact the only strict demand
i an aware off from the inventor is don't call it REST if all the
constraints are not applied :-)
Paul.