ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: REST and decoupling Was: [gsoc] Monitoring Console / Architecture
Date Tue, 20 May 2008 06:38:32 GMT
On Mon, May 19, 2008 at 9:36 PM, Zubin Wadia <zwadia@gmail.com> wrote:
> Sanjiva,
>
> I am confused by your comments. Where in Assaf's post did he mention that
> WSDL cannot be torn out without breaking the client?
>
> Additionally, I can't understand how Assaf's comment about JSON implies its
> superiority over XML in RESTful architectures. The message I inferred was:
> Good solutions are a result of precient design that isn't a prisoner of the
> tools & frameworks.
>
> Seems like a perfectly legitimate premise and one I agree with.
>
> God only knows why this became a REST vs. WS-* debate, I think that's
> precisely what he was trying to avoid with the last sentence of his post!

Thanks!

Assaf

>
> Cheers,
>
> Zubin.
>
> On 5/19/08, Sanjiva Weerawarana <sanjiva@opensource.lk> wrote:
>>
>> Assaf Arkin wrote:
>>
>>> Besides the management console, we have three other ongoing projects in
>>> Ode.
>>>  One adds HTTP binding and REST support to the engine, so you can use Ode
>>> to
>>> interact with and develop services conforming to the Web architecture.
>>>  You
>>> could build a JavaScript front-end to interact with the process, or have
>>> the
>>> process tap into services that don't pay the WS-* tax.  In certain cases,
>>>
>>
>> Ah, a true fan of WS-* ;-).
>>
>>  The best way to start is to start small, but always keep an eye on the
>>> target.  You don't have to do JSON in the first release, just XML may be
>>> good enough, but watch out that your data model can map nicely to either
>>> one, because XML magically mapped to JSON has neither the benefit of being
>>> XML nor the benefit of being JSON.
>>>
>>
>> JSON or XML or plain text or whatever has absolutely no impact on whether a
>> design is RESTful or not. You appear to be suggesting that somehow JSON is
>> more RESTful than XML .. which really is somewhat ironic given the "O" in
>> JSON stands for "object" :).
>>
>>  You don't have to do any PUT or DELETE,
>>> maybe your first service is just a lot of queries, but watch out that
>>> you're
>>> not building something that can never accommodate for that.  A good idea
>>> is
>>> to look at REST as an interface and see if you can tear out and replace
>>> the
>>> implementation without breaking all your clients: are the resources you're
>>> using well thought out, or could they only be implemented by FooBar?
>>>
>>
>> Sorry but this is hogwash. I don't disagree with most of your post but to
>> suggest that a service interface described in WSDL cannot be torn out and
>> replaced without breaking clients is silly. That's *exactly* what WSDL was
>> designed for. REST nor any other approach to architecture automatically
>> guarantees proper decoupling; that requires careful design.
>>
>>  There's a lot of fascination with XHR, which can be put to good use to
>>> enhance a service.  But there are also ways to use XHR to hide the service
>>> from the world.  Can I bookmark this page and return to it later?  Can I
>>> IM
>>> this link to someone else so they can look at it?  Can I subscribe to
>>> changes from my feed reader or pull this into my calendar?  Can I have a
>>> widget that shows this content on my desktop?  The temptation to build
>>> desktop-like applications that are closed off the Web is there, but best
>>> ignored.
>>>
>>
>> XHR is useful and necessary to make your interface more interactive.
>> Otherwise you have to load a brand new entire page everytime something is
>> done .. which most people consider 90s style Web UI design rather than
>> modern design. Obviously YMMV.
>>
>>  If you want the benefits of REST, always think how to keep clients
>>> decoupled
>>> from servers, and which principles - not tools - will get you there.
>>>
>>
>> To get the benefits of REST you have to go beyond decoupling- you have to
>> design a set of interlinked resources that are easily navigable by clients.
>> I agree that tools cannot do that.
>>
>> Sanjiva.
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>> Member; Apache Software Foundation; http://www.apache.org/
>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>
>>
>

Mime
View raw message