A criticism of SOAP/WSDL is the low-level procedural focus, which is very different from the model that has been successful for the web:
- A URL/URI refers to a unique resource which can be retrieved via HTTP.
- Focus is on retrieving data referenced with a particular name, as opposed to executing a sequence of operations.
- Rather than specifying how a client should interact with a service, we specify a reference to a data object in the form of a URI.
- Web as a shared information space, rather than as a medium for transporting messages between hosts. Encryption must be done at the network level if security is a concern.
cons: Challenging to encode data structures in a URI
Why use web? port 80 is open.
Amazon, Google Maps, Twitter, Yahoo!, Technorati, ... Now people are starting to require signed requests however. a serious pain, but understandable.
REST stands for Representational State Transfer
- Idea: Applications work with a representation of a resource (i.e. an XML representation of a song)
- These representations are shared, or transferred between components.
- These representations allow client applications to manage their state.
- Data-centric: all services and resources can be referenced with URIs.
- Servers respond to a request by providing a representation of an object.
XML or JSON is returned by the server. The client must determine how to validate and parse this, hopefully with the help of a schema.
REST is really more of an architectural model than a protocol. A recipe for building web-scale applications. In practice, it refers to:
- encoding requests within an URI
- using HTTP to deliver them
- returning results via XML/JSON
Twitter REST api console
Twitter Python interface