On 04/07/06, Stuart Charlton <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > --- Steve Jones <[EMAIL PROTECTED]> wrote: > > > What is the real-world effect of calling PUT? > > What is the business value of calling put? > > > The resource (URI) + the method defines the business > value. > In the small, to a single consumer, the value of > splitting these two is negligible (vs. a more > traditional, business-aligned operation like > "putSomethingHere").
I love the implication that business aligned is a bad thing. But to the point, there is no business value in PUT, its the actual EXECUTION that gives the value. > > > > Describing PUT as the operation is a bit strange to > > me as it has > > neither value nor effect. > > > The value is in the network effects generated by > everyone agreeing to an operation that means "replace > state idempotently". Which is... zero? > > The value is the large -- through network effects that > result when one factors out some broad agreements. > If we all agree on a universal way to PUT something, > somewhere, idempotently, we have a lot of value. No we don't, we have a mechanism to deliver value, and there is a difference. > > Of course, none of this helps the individual > developer who wants A to consume B. It helps the > network out (and developers that want to take > advantage of the network), and leads to many returns > .... So its about helping the system not the individuals? Maybe its me, but I think that (and I speak as a developer of sorts) developers making decisions is one of the major reasons that IT is in the mess it is. We become obsessed with technology and completely lose track of the business value and objectives. > > ... Having said this, I've seen countless developers > curse HTTP as the most evil / awful protocol in the > universe because they can't develop applications the > way THEY want to (stateful, conversational, > transactional, etc.) , regardless of whether such > approaches are possible in a widely decentralized > system... All it indicates is there are plenty who > don't care about the network (rightly or wrongly), > they just want to get their part of the world done. Again, I'm not interested in developers, I'm interested in architects and business people. I want to reduce the complexity of the IT environment and for it to work in the way that the BUSINESS wants rather than constraining the business with technological fads from IT. > > Thus, If you're focused in the small (where small = > within a department, division, etc.), SOAP/WSDL in an > IDE is hard to beat. REST in a dynamic language is > comparible. Perhaps this is why the argument > continues ;) Oddly I'm focused in the large (global, inter company etc) and SOAP/WSDL appears to be working fine too... Or maybe why the argument continues because IT is allowed to keep arguing because we aren't seen as a professional group of people. Railways would be "better" if you had wider gauge rails, but we've standardised on one approach because that makes more sense than having pointless discussions. This is my point, not that REST is rubbish or SOAP rocks, but that the implementation of the execution context is of NO VALUE at all to the business, and having multiple approaches and multiple arguments reduces the value available, increases the complexity and reduces the focus away from solving the NEXT problem onto re-solving the current one. > > Cheers > Stu > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > > ------------------------ 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/
