Slashdot Mirror

There is one good RPC system, and it's called HTTP. It works wonderfully when you can generate stuff from a database into some text-representation.

The people behind REST seem to agree with you, I think.

Here are some links. See esp. the REST Wiki:
Adam Bosworth's Weblog: Learning to REST
Bitworking - The Well-Formed Web - REST
Debate foams over SOAP 1.2 - REST versus SOAP
How To Convert Rpc To Rest
http://www.xfront.com/ - REST Tutorial, XML et al - Roger Costello's site
ITworld.com - XML IN PRACTICE - XML, Web Services, and the REST Architecture
Mark Baker, Tech Curmudgeon - REST - Transport, transfer and coordination in HTTP
O'Reilly Network: REST vs. SOAP at Amazon [June 24, 2003]
Paul Prescod's REST Resources
Reliable delivery in HTTP - REST
REST A Web-Centric Approach to State Transition - Paul Prescod
REST could burst SOAP's bubble - Hoobler
REST Faq - Alternative to SOAP XML
REST SlideShow: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction
REST wiki - Representational State Transfer - alternative to SOAP XML
rest-discuss Message 2330 - ROP vs RPC vs OOP pt 1
Roots of REST - SOAP Debate - Paul Prescod Yahoo! Groups : rest-discuss Messages :Message 1314 of 1646
Roy T. Fielding - REST Architect
Sean McGrath BLOG - REST proponent
W3C mailing-list search service on REST
Why you should not use RPC for GET
xml-dev - Re: [xml-dev] SOAP-RPC and REST and security
XML.com: In a Lather About Security - SOAP security vs REST security
Yahoo! Groups : rest-discuss Messages : 2371-2428 of 2428

Here are some links. See esp. the REST Wiki:
Adam Bosworth's Weblog: Learning to REST
Bitworking - The Well-Formed Web - REST
Debate foams over SOAP 1.2 - REST versus SOAP
How To Convert Rpc To Rest
http://www.xfront.com/ - REST Tutorial, XML et al - Roger Costello's site
ITworld.com - XML IN PRACTICE - XML, Web Services, and the REST Architecture
Mark Baker, Tech Curmudgeon - REST - Transport, transfer and coordination in HTTP
O'Reilly Network: REST vs. SOAP at Amazon [June 24, 2003]
Paul Prescod's REST Resources
Reliable delivery in HTTP - REST
REST A Web-Centric Approach to State Transition - Paul Prescod
REST could burst SOAP's bubble - Hoobler
REST Faq - Alternative to SOAP XML
REST SlideShow: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction
REST wiki - Representational State Transfer - alternative to SOAP XML
rest-discuss Message 2330 - ROP vs RPC vs OOP pt 1
Roots of REST - SOAP Debate - Paul Prescod Yahoo! Groups : rest-discuss Messages :Message 1314 of 1646
Roy T. Fielding - REST Architect
Sean McGrath BLOG - REST proponent
W3C mailing-list search service on REST
Why you should not use RPC for GET
xml-dev - Re: [xml-dev] SOAP-RPC and REST and security
XML.com: In a Lather About Security - SOAP security vs REST security
Yahoo! Groups : rest-discuss Messages : 2371-2428 of 2428

Here are some links. See esp. the REST Wiki:
Adam Bosworth's Weblog: Learning to REST
Bitworking - The Well-Formed Web - REST
Debate foams over SOAP 1.2 - REST versus SOAP
How To Convert Rpc To Rest
http://www.xfront.com/ - REST Tutorial, XML et al - Roger Costello's site
ITworld.com - XML IN PRACTICE - XML, Web Services, and the REST Architecture
Mark Baker, Tech Curmudgeon - REST - Transport, transfer and coordination in HTTP
O'Reilly Network: REST vs. SOAP at Amazon [June 24, 2003]
Paul Prescod's REST Resources
Reliable delivery in HTTP - REST
REST A Web-Centric Approach to State Transition - Paul Prescod
REST could burst SOAP's bubble - Hoobler
REST Faq - Alternative to SOAP XML
REST SlideShow: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction
REST wiki - Representational State Transfer - alternative to SOAP XML
rest-discuss Message 2330 - ROP vs RPC vs OOP pt 1
Roots of REST - SOAP Debate - Paul Prescod Yahoo! Groups : rest-discuss Messages :Message 1314 of 1646
Roy T. Fielding - REST Architect
Sean McGrath BLOG - REST proponent
W3C mailing-list search service on REST
Why you should not use RPC for GET
xml-dev - Re: [xml-dev] SOAP-RPC and REST and security
XML.com: In a Lather About Security - SOAP security vs REST security
Yahoo! Groups : rest-discuss Messages : 2371-2428 of 2428

Not just using POST for changing state server side and GET for other stuff is a mistake that is often made...

The REST stuff is good on this...

Also the W3C document on URIs, Addressability, and the use of HTTP GET and POST, a document being debated on the W3C Technical Architecture Group (TAG) list is debating at the moment [ thread 1 | thread 2 ] also well worth reading...

I wonder if REST is covered in this book?

RESTful web services are the services primarily in place today: they utilize existing WWW security standards, are easy to implement and debug, and are available today.

• REST Wiki
  
• Building Web Services the REST Way
  
• Paul's REST Resources
  
• REST and the Real World
  
• Second-Generation Web Services
  

Now the pressing question seems to be the RESTfulness or not of Web Services. See a related Mark Baker's blog entry for illustration.

... RPC-style "web" services such as SOAP and XML-RPC should not be an option. They're contrary to the architecture to the Web. If anything, they should be called RPC over HTTP or something similar, because that is all they have in common with the Web.

If you want to do a real Web service, use REST.

On the plus side, the fusebox framework brings some organization to what would otherwise be a collection of interconnected pages of script. Fusebox is fairly straightforward and a developer can use it with a single day of instruction, so it can be a very useful application development tool.

OTOH the resulting application is usually a single large executable which handles all functions (and pages). This is not in itself a bad thing, but appears to be precariously close to the Big Ball of Mud methodology of software development, although it really isn't.

Until something better comes along for scripting languages complex applications can be organized using fusebox. And at that time it shouldn't be difficult to refactor an application from the fusebox framework to another, better methodology.

The REST methodology approaches applications development from another perspective and is grounded in the structure of the WWW: it may be the next place to look for organizing WWW applications development.

• Death of the Browser? (on Microsoft's site) and
  
• The Return of Client/Server -- or, at Least, Rich Clients
  

But first go see how Debate foams over SOAP 1.2 in the W3C working groups for XML, SOAP and Web Services.

It seems that Roy Fielding, one of the key architects of HTTP and a member of the W3C TAG (Technical Architecture Group), which essentially defines the principles of Web architecture inside the W3C, pointed out that the SOAP specification broke universally-accepted WWW protocols and would be unlikely to succeed. At the same time Fielding and others have pointed out that Web Services can easily be implemented today including all desired security and authentication by using current WWW protocols and by judicious use of what he calls a REST Architecture, a subset of the current WWW architecture.

Microsoft's plan is unlikely to work: the members of the involved working groups have realized that failure of SOAP to be consistent with WWW will doom it to failure because of the additional complexity and lack of scalability that would entail.

See also

• Paul Prescod's Home Page and especially the section "HTTP and REST" wherein he elucidates the subtleties of REST and how SOAP breaks the WWW. Prescod is one of the most vociferous and well-written supporters of the REST architectural style in the W3C working groups.
  
• A REST Tutorial for Roger Costello's brief but excellent introduction to Roy Fielding's REST and why it will be the basis for any viable Web Services architecture.
  
• Visit the REST Wiki to relax in an oasis of ideas that explains how Web Services can be implemented today in a manner
  
  • not as complex as the proprietary vendors and current and pending specifications of SOAP appear to require,
    
  • using the technology and tools you already know.

Finally, dive into the waters of the oasis and wash the SOAP off of your soul. Now pure of heart, make a pilgrimage to Tim Berners-Lee's Design Issues for the World Wide Web where you can

• re-examine the issues of the WWW,
  
• renew your commitment to doing things "the right way",
  
• revive your passion for excellence and
  
• remind yourself that indeed, sometimes "less is more."
  

• Death of the Browser? (on Microsoft's site) and
  
• The Return of Client/Server -- or, at Least, Rich Clients
  

But first go see how Debate foams over SOAP 1.2 in the W3C working groups for XML, SOAP and Web Services.

It seems that Roy Fielding, one of the key architects of HTTP and a member of the W3C TAG (Technical Architecture Group), which essentially defines the principles of Web architecture inside the W3C, pointed out that the SOAP specification broke universally-accepted WWW protocols and would be unlikely to succeed. At the same time Fielding and others have pointed out that Web Services can easily be implemented today including all desired security and authentication by using current WWW protocols and by judicious use of what he calls a REST Architecture, a subset of the current WWW architecture.

Microsoft's plan is unlikely to work: the members of the involved working groups have realized that failure of SOAP to be consistent with WWW will doom it to failure because of the additional complexity and lack of scalability that would entail.

See also

• Paul Prescod's Home Page and especially the section "HTTP and REST" wherein he elucidates the subtleties of REST and how SOAP breaks the WWW. Prescod is one of the most vociferous and well-written supporters of the REST architectural style in the W3C working groups.
  
• A REST Tutorial for Roger Costello's brief but excellent introduction to Roy Fielding's REST and why it will be the basis for any viable Web Services architecture.
  
• Visit the REST Wiki to relax in an oasis of ideas that explains how Web Services can be implemented today in a manner
  
  • not as complex as the proprietary vendors and current and pending specifications of SOAP appear to require,
    
  • using the technology and tools you already know.

Finally, dive into the waters of the oasis and wash the SOAP off of your soul. Now pure of heart, make a pilgrimage to Tim Berners-Lee's Design Issues for the World Wide Web where you can

• re-examine the issues of the WWW,
  
• renew your commitment to doing things "the right way",
  
• revive your passion for excellence and
  
• remind yourself that indeed, sometimes "less is more."
  

• Death of the Browser? (on Microsoft's site) and
  
• The Return of Client/Server -- or, at Least, Rich Clients
  

But first go see how Debate foams over SOAP 1.2 in the W3C working groups for XML, SOAP and Web Services.

It seems that Roy Fielding, one of the key architects of HTTP and a member of the W3C TAG (Technical Architecture Group), which essentially defines the principles of Web architecture inside the W3C, pointed out that the SOAP specification broke universally-accepted WWW protocols and would be unlikely to succeed. At the same time Fielding and others have pointed out that Web Services can easily be implemented today including all desired security and authentication by using current WWW protocols and by judicious use of what he calls a REST Architecture, a subset of the current WWW architecture.

Microsoft's plan is unlikely to work: the members of the involved working groups have realized that failure of SOAP to be consistent with WWW will doom it to failure because of the additional complexity and lack of scalability that would entail.

See also

• Paul Prescod's Home Page and especially the section "HTTP and REST" wherein he elucidates the subtleties of REST and how SOAP breaks the WWW. Prescod is one of the most vociferous and well-written supporters of the REST architectural style in the W3C working groups.
  
• A REST Tutorial for Roger Costello's brief but excellent introduction to Roy Fielding's REST and why it will be the basis for any viable Web Services architecture.
  
• Visit the REST Wiki to relax in an oasis of ideas that explains how Web Services can be implemented today in a manner
  
  • not as complex as the proprietary vendors and current and pending specifications of SOAP appear to require,
    
  • using the technology and tools you already know.

Finally, dive into the waters of the oasis and wash the SOAP off of your soul. Now pure of heart, make a pilgrimage to Tim Berners-Lee's Design Issues for the World Wide Web where you can

• re-examine the issues of the WWW,
  
• renew your commitment to doing things "the right way",
  
• revive your passion for excellence and
  
• remind yourself that indeed, sometimes "less is more."
  

Everyone who even pretends to be able to knock up websites, hack PHP and CGI scripts etc should be familar with REST; it's one of the core concepts behind the web.

The REST Wiki is a good place to start.

For those of you like me that have no clue what REST is (REpresentatational State Transer) here's a decent wiki page I found on it.

I wrote "Web RPCs Considered Harmful" that briefly addresses the security issue.

Summary (and using more recent terminology): Web services that expose more new and unique code are more likely to expose bugs. RPCs, SOAP, and CGIs all encourage developers to write more exposed code by making that style easier to do.

One better alternative is to be more data-driven (some would say "functional", as in "functional programming"), so that you only expose data (via a standard server which would typically be more mature, heavily reviewed code).

Alas, that's an entirely different way of thinking that most people are not used to, since it flies in the face of "normal procedural or OO programming" that happens on the desktop. Some examples, though, are Linda Systems (TupleSpaces), REST (the traditional WWW architecture), and even P2P to a large extent.

This is a really important debate right now, and there are no good answers. The debate comes down to how much do we need to do to the Web as we have it today to be able to create an environment where programs can be as interoperable as web browsers and servers are today?

There are growing criticisms of the consensus vision of web services -- http / SOAP / WSDL / UDDI -- largely on the grounds that its complexity is un-web-like, and that there are uninvented and possibly uninventable layers required above UDDI for any two arbitrary applications to be able to find each other in the dark.

Dave Winer of Userland, inventor of XML-RPC and co-designer of the SOAP spec, advocates an embrace of these two protocols by the Open Source movement as a lightweight way to advance the battle for interoperability. (Dave's ideas in many ways answer the Will Open Source Lose the Battle for the Web? article form earlier this month.)

Another group, in line with your "Apache is all we need" idea, has taken Roy Fielding's idea of the REST (REpresentational State Transfer) architecture as a way to extend existing web semantics furhter into the domain of applications. They have started a RESTWiki to expand on those ideas.

This is all a big mess right now, with no obvious clarity coming any time soon, but two things we can be certain of are that experiments with application-to-application traffic is going to increase dramatically in the next 12 months, whatever the framework, and that with MSFT driving this idea as part of .NET, even if a lot of it is hype, it will affect our world a great deal.

-clay