REST (Representational State Transfer) is a simple way of transferring content using HTTP protocol. REST does not need to contain any XML (like SOAP), and can be provided and consumed using a simple URL.
The REST software architecture involves clients (consumers) and servers (providers); the consumer initiates requests and the provider processes the requests, and may deliver the information back to the consumer. The consumer of a REST Web Service points to a single service, identified by a URL. For example, a provider makes their service available through a URL query line; the consumer sends data (a request) to the URL and may receive a response from the provider. A typical REST URL might look like this: http://localhost:8080/OrderStatus?ParmA=1&Parm2=B
When inspecting the above URL query line, there are several types of information being communicated:
HTTP Request Methods, Status Codes, and Header Fields
- GET: Retrieves data/resource
- PUT: Updates data/resource
- POST: Creates data/resource
- DELETE: Deletes data/resource
When a consumer sends a request, the provider returns HTTP status codes that show whether the request was received; it also includes one of several status descriptions:Processing (1xx), Successful (2xx), Redirection (3xx), or indicating Client (4xx) or Server errors (5xx).
HTTP header fields are components of the message header of requests and responses used in HTTP. They define additional information about the request to and response from the Service provider. This additional information may be sent with the status codes. This may include required authentication info, such as user name and password, or just additional information about the requester. They can be used to override common headers, or create custom ones. Examples of common header fields include cookie, ETag, Location, HTTP referer, DNT, and X-Forwarded-For.
In Clarify's Web Service Consumer and Provider objects (for REST), this HTTP Header information will be used in the related Request and Response actions.
Advantages & Disadvantages
Generally REST is easier to setup and implement from a provider's standpoint, however it's important to consider both the pros and cons.
- Easier to build and maintain
- Lacks security standards
- Tied to HTTP
- Point-to-point communication (as opposed to distributed computing)