The Representational State Transfer (REST) API can be a conundrum. A lot of information obfuscates what in its essence is a very straightforward concept.
The REST API is not strictly speaking an “API”, if you refer to the HTTP protocol verbs. REST, in the words of its originator Roy Fielding, is an “architectural style”. Specifically, it is a set of guidelines that hinge on the HTTP protocol specifications. See http://www.w3.org/Protocols/.
Why should you care about this mambo jumbo? Well, believe it or not,this style is the corner stone of all the Cloud (Web) services. At its core a Cloud service is stateless. All the information about state is on the client side. For example, if you take a web page, once it has been delivered to the client, there is no memory on the server side keeping track of “what to do next”. What to do next, that is all the state information, is in the page itself in terms of hyperlinks. In essence, besides its HTML content, the hyperlinks in the page are the representational state transfer.
REST guidelines instruct the developers to use HTTP verbs explicitly and in a way that it is consistent with the protocol definition. This means a one-to-one mapping between create, read, update, and delete (CRUD) operations and HTTP verbs as follows:
- Create a resource with POST
- Retrieve a resource with GET
- Update a resource with PUT
- Delete a resource with DELETE
You can find more verbs here.
Why is REST Popular?
Because HTPP is ubiquitous, as a higher protocol in the application layer of the OSI model, the HTTP (REST) verbs have become the minimalist, effective and standard way to exchange information (text, images, videos and so on) on the Internet.
The following figure shows where the HTTP protocol is located in the OSI model:
Where is the API?
Well, any company that is in the web services business (shall we say Cloud), provides a set of libraries to support the most common programming languages (Java, Python, C#, etc…). A programmer can use a familiar programming language to perform requests associated with HTTP verbs. She must know a company specific library to make API calls. The library translates the calls into the appropriate HTTP verb requests. It also fills the HTTP protocol details such as header information.
The following is a logical diagram, albeit a simplified one, of the main components involved in a RESTful exchange:
The following code examples show how to list the objects in a bucket (stored in a public cloud storage “the service”):
- The following code examples show how to list the objects in a bucket (stored in a public Cloud storage “the service”):
def listObjects(bucketName, service): print 'List objects contained by the bucket "%s".' % bucketName fields_to_return = 'nextPageToken,items(bucket,name,metadata(my-key))' request = service.objects().list(bucket=bucketName, fields=fields_to_return) response = request.execute() print json_dumps(response, indent=2)
Storage.Buckets.List listBuckets = service.buckets().list(settings.getProject()); buckets = listBuckets.execute(); for (Bucket bucket : buckets.getItems()) { displayMessageHeader("Getting bucket " + bucket.getName() + " metadata"); displayBucketInformation(bucket); }
Under the hood, a GET request is issued. But you do not see it in the code snippet above.
What you see is an API call as highlighted.
Only wanna input that you have a very decent site, I love the style it really stands out.
Thank you
Your style is so unique in comparison to other people I have read stuff from.
I appreciate you for posting when you have the opportunity, Guess I will just
book mark this page.
Thank you