I agree completely, but this has little to do with the REST vs <something else> issue. REST may be very "reusable", but the data being sent over it may not. In activity-oriented applications, one needs to have a fairly rich vocabulary. In this case, some of the "interface" needs to be embedded in the data. This is fine, but if each user expresses this differently, then it is pretty much non-interoperable. One needs to have reusability in REST non-only in the top level interface, but in the internals of the data being sent. REST mixes up the data with the operations in this more complex example, which doesn't simplify the problem but can make it more complex.
Dave Mark Baker wrote: > > On 7/11/06, David Forslund <[EMAIL PROTECTED] > <mailto:forslund%40mail.com>> wrote: > > My question is what does REST really bring to the table. > > I guess we've been trying to explain that in recent days on the list. > I think it pretty much comes down to this; the more general the > interface, the more reusable the implementation. > > Mark. > > __ > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Check out the new improvements in Yahoo! Groups email. http://us.click.yahoo.com/6pRQfA/fOaOAA/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/
