Cart
[Home] [By Thread] [By Date] [Recent Entries]
Alexander said: > if you are dealing with specific objects, I guess they're > resources like other resources, no? Typically not, in my experience. Objects are finer grained and designed for purposes other than external interface needs. > I think this more comes down to the definition of an object. Is there > a difference between an object and a resource? In the broad definition > of "resource", then no. In terms of REST, you can perfectly well > design objects that cater to that architectual style. The problem is > that "object" can be a lot of things, and specifically things that > don't fit into the REST way of doing things even if you expose them > through it. My point here is that the potential for abuse is too high. The OO folks will go ahead and design object models the way they always have, or will reuse existing models, and then just slap some HTTP on top of them with some URLs that reference those objects, and will REST on the 7th day. And then the distributed systems granularity and RPC issues will raise their ugly heads yet again. At least, in the real world, that is my prediction of what the Objects at REST suggesting will inevitably lead to. > Again, we're back to the old "if done right, then yes, and if done > wrong, then no" explanation. I predict way more wrong than right will be inflicted on business stakeholders and IT management with this approach. ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
