Jan Algermissen wrote: > On Jul 11, 2006, at 5:54 PM, Dan Creswell wrote: > > >>And as it appears that's what you'd have to do many people are >>wondering >>how that's much better than defining it all on some contract/interface >>be it implemented via RPC or some other mechanism. > > > Because there will be integration at some point and with e.g. RPC you > have to deal with: > > - the behavioural contract
The service on the other end of a REST operation must have some behavior right? If I change "the data" arbitrarily, I don't think that either RESTful or RPC applications are going to fair any different in dealing with my "random" data. > - the API It is not a requirement to change the API in order to change "the data". This seems to be a main theme in the arguments for REST. It is perfectly possible to define an API, the first time, which will never need changing, whether it's RESTful or not... > - the data > > with REST you only need to consider > > - the data > > IMHO it is much easier to *only* having to translate between > different data representations of state than it is to translate > between different behavioural and API contracts *and* the data. This is just not making sense to me. How in the world can you imagine that the user of the RESTful PUT state can deal with any possible data? At some level that application has to understand "the data". It is the data design that makes the most value in reducing API rework in RPC style applications. If you pass around "String" and "int" in your parameter lists, than yes, you'll probably get to make changes. If you instead embody the data that is traversing the API in proper object modeling (I am assuming that you have an object oriented language, and more importantly I am asserting that Java provides a lot of value in RPC applications as well as others), you'll not have to worry about all this API change that keeps comming to the top of these discussions. And yes, you can model an object system using strings. But, that representation, for me, is the last choice I would make, not the first. Gregg Wonderly ------------------------ Yahoo! Groups Sponsor --------------------~--> See what's inside the new Yahoo! Groups email. http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
