Many developers will be surprised to learn that SOAP isn’t the only game in town for Web services interfacing. REST offers a perfectly good solution for the majority of implementations, with greater flexibility and lower overhead. Developers need to stop reaching immediately for SOAP and start choosing the right technology for the application.
What is REST?
Born of a UC-Irvine doctoral dissertation by Roy Fielding in the year 2000, REST has grown into a force in the application development community, offering a simplified method of using HTTP protocols to work directly with data.
Fielding describes REST as an architectural style that leverages the modern Web, adding “REST emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.”
Delving into the short definition of REST, a basic use case for it would be an online publisher making available syndicated content. Subscribers would need only to know the URL (Uniform Resource Locator) for the page where the XML file was located, read it with a Web browser, interpret the content data, and reformat and use it appropriately.
- Overview of REST in WCF (http://msdn.microsoft.com/en-us/netframework/dd547388.aspx )
- What is REST(http://rest.blueoxen.net/cgi-bin/wiki.pl?WhatIsREST)
- Representational State Transfer – REST Tutorial (http://searchsoa.techtarget.com/generic/0,295582,sid26_gci1317288,00.html)
- How I Explained REST to My Wife (http://tomayko.com/writings/rest-to-my-wife)
- REST (http://www.xfront.com/sld001.htm)
- REST vs. SOAP (http://www.innoq.com/blog/st/2006/06/30/rest_vs_soap_oh_no_not_again.html)