Source: http://www.qualitylogic.com/Contents/Enterprise/Technology/XML-SOAP-REST.aspx
Source: Quality Logic
REST (Representational State Transfer)
SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) provide mechanisms for requesting information from endpoints (SOAP) or from resources (REST). Perhaps the best way to think of these technologies is as a method of making a remote procedure calls against a well-defined API. SOAP has a more formal definition mechanism called WSDL (Web Services Definition Language) and is a bit more complex to implement. REST uses the standard HTTP request and response mechanism, simplifying implementation and providing for a looser coupling of the client and server. Note that REST also supports the transfer of non-XML messages such as JSON (JavaScript Object Notation). For more about SOAP, see Wikipedia or W3.org; for more about REST, go to Wikipedia or A Brief Introduction to REST on InfoQ.
Testing a web services API implementation requires the same discipline and methodologies as with any core technology test effort. Formal test specifications, test cases with well-defined assertions, and a robust test execution platform are all part of a successful web services test effort.
Most major web properties, such as Yahoo, Google, YouTube, and Flickr, provide a web services API so that web site developers can pull information from their sites. In fact, a class of web sites exist called mashups, which pull data from a variety of sources using web services and combine the data in innovative ways. Validating a mashup or any web site that pulls data from external sources requires careful testing to ensure that the client can handle all possible variations of the received data.
REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.). Later, we will see how much more simple REST is.
