These days, REST APIs are available to integrate your application or website with thousands of platforms -- Web 2.0 properties such as Twitter, Facebook, and Foursquare, as well as old-school companies like USA Today, Best Buy, and Edmunds.com. Unfortunately, tapping this dizzying buffet of options isn't always easy.
Most API documentation assumes an understanding of the foundational technology, and while REST API architecture gives developers enormous freedom to innovate, that freedom comes at a price -- namely, fewer guidelines for application behavior. But because these APIs are based on HTTP, a mature protocol, there are numerous strategies you can use to develop and debug your application. First, though, you need a comprehension of the basics of HTTP, a grasp of REST architecture, and some tools for inspecting traffic and strategies for debugging problems.
[ Experts explain all key HTML5 specs, from canvas to local storage, plus the latest browser benchmarks and report cards on HTML5 support in InfoWorld's megaguide to HTML5. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
HyperText Transfer Protocol (HTTP) -- the protocol used throughout the Internet for transactions between Web servers and clients -- is simple, tested, and supported by libraries in every modern programming language. HTTP includes methods supporting all of the necessary actions for a server/client transaction: PUT, GET, POST, and DELETE. It has a rich set of status codes to cover success and error situations, and headers and query parameters make it possible to send additional information about the transaction or request to the server.
To better illustrate how HTTP works, let's take a look at a simple transaction. This is a basic request from a Chrome browser on a Macintosh to Google's home page.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3)
Looking over the request, you can see that the method sent (1) was GET -- a read operation on an HTTP resource. The URL (2) indicates the full path being retrieved -- in this case, the document at the root of
http://www.google.com. The request gets a little more interesting with the headers (3). An HTTP transaction can have any number of headers, and these allow the client to send information about the transaction to the server.
In addition to the types of headers seen here, headers can also be used to send user-specific information such as cookies. Servers aren't under any obligation to use information passed along via headers, but they frequently use the information to craft the response appropriately -- HTML that will display nicely on a specific browser, or content in the language the user prefers.
Content: <a bunch of html>
Content-Type: text/html; charset=UTF-8
Date: Fri, 11 May 2012 21:26:46 GMT