Re: [rest-discuss] Objects at REST...

["Andrzej Jan Taramina" <andrzej@chaeron.com>]

Daniel suggests:

> otherwise we treat methods as subordinate URLs of
> the parent objects (e.g. /articles/1/publish()), but it only accepts
> GET (we return a representation to fill the parameters and submit it,
> usually is a xhtml form but it can be something else for other
> media-types) and POST for invocation responding with redirect. It will
> emphasize not using RPC style methods but if you must it should use
> safe semantics.

That's the start of a very slippery slope.  You're basically encouraging the 
OO folks to tunnel RPC over HTTP.

I think we've had enough discussions of why that is not such a good idea on 
the rest forums already.

But you just proved my point...thanks!

> Obviously I'm biased for it but I think it's a good way to develop an
> application, because the user's interface will map the domain model.

That doesn't work in the world of machine to machine communications, since it 
is rare that disparate systems have common domain or object models.  

The better approach in that scenario is to design a data representation 
format that is better suited to the integration and transmission of 
information, rather than cater to internal implementation models on both 
sides.

> As we can use URIs to identify objects we can save those in other
> systems, so we are planning to use URIs for every inter application
> references, which lends itself to very easy integration. 

I beg to differ.  Common/consistent URI's are a help, but a properly designed 
data representation, with concomittent semantic definitions, independent of 
back end domain/object models is what makes integration easier, though even 
at the best of times, integration is still hard.


> Also if the
> only interface to your app is via REST, everything can be an WS
> without additional effort.

What you're doing isn't REST for the most part.  It's using HTTP as a 
transport mechanism for RPC and inter-object distributed communications.

 It's also great because you think much more
> about your domain and don't worry with user interfaces, because this
> problem is solved, so essentially you know that in the interface you
> can just navigate via URIs and find what do you want (e.g.
> /authors/Joe_Blogger/posts?published=false) which makes much easier to
> write ajax widgets in the app without up front design.

You are mixing metaphors.  Integration is not an Ajax-based activity 
(usually), since Ajax is geared towards user UIs, not machine to machine 
integration, the latter being the much harder problem to solve, and providing 
much more benefit when it is solved (think healthcare for a good example of 
this).


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com