|
|
Featured White Papers
- Why choose an Open Source BPM?
- 10 FAQs on Business Process Management
- Best Practices for Getting Started with BPM
- Free Your Devs From The Pain Of Java Redeploys
- Increase Velocity 40% by Using JRebel
- What Developers Want: The End of Application Redeploys
- Developer Productivity Report: Java Tools, Tech, Devs, and Data
- Coding with JRebel: Java Forever Changed
- Utilizing Fast Testing to Transform Java Development
- Do You Really Get Classloaders?
- Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
- Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
- Coding with JRebel, Java Forever Changed
- 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data
Sponsored Links
Sponsored Links
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
How-to: REST Web services demystified
REST API integration needn't be daunting -- get started with web services
Page 2 of 5
- 50x: Something went wrong with the server.
- 40x: The developer did something unexpected.
- 30x: These codes are used for redirects.
- 20x: Cool, your request succeeded.
Watching HTTP traffic
With a basic understanding of how these transactions work, it's time to take it to the next level and watch some actual traffic.
Fortunately, because HTTP is so widely used, it's easy to find traffic to inspect even before you start accessing the APIs.
Many modern Web browsers provide a Web inspector function that allows you to see the browser's traffic. However, since the
focus of this article is on software development using REST APIs, you'll need to use an application that lets you watch all
of the HTTP traffic flowing to and from your system -- not just your browsing activity.
HTTP sniffers
HTTP sniffers are applications that provide a console to view the Web traffic on your system. All of them report on the transaction
information detailed above: the URL, headers, method, and body of the request; and the status, headers, and body of the response.
On the Macintosh, HTTP Scoop works quite well. On Windows, I suggest Fiddler, and for Linux/Unix systems there's Wireshark.
As an example, here are a few screenshots from HTTP Scoop. The first one shows the summary view with basic information about the request.
Double-clicking on one of the log lines gives a more detailed view of that particular transaction.
In the case of HTTP Scoop, you're provided with different tabs to explore specific aspects of the transaction. The Headers tab is frequently useful in understanding the request and response.
Being able to inspect the headers for the transaction gives you a lot more information about how the client and server are communicating. Another particularly useful tab in this tool is Request/Response, which shows the GET parameters and POST body as well as the body of the server response.
You can almost always figure out what's going wrong with a request using a combination of the Headers and Request/Response tabs (or the equivalent in one of the other sniffers). If you can create a successful request, and compare the values to your failing request, it's generally fairly easy to figure out what you need to change in order to fix the issue.
Install one of these sniffers on your system and experiment with it a bit. Visit a Web page and make sure you can find all of the important components of the requests and responses listed above.
REST
This section provides a very high level (and somewhat abstract) overview of REST API architecture. If you want to dig a little
deeper into REST, there's a fantastic tutorial at rest.elkstein.org. REST, for "Representational State Transfer," is a lightweight architecture for network applications that use HTTP requests
to read and write data. Because REST services are built on this well-supported standard, these APIs are platform independent,
and standard libraries for facilitating these simple Web requests are available in all modern programming languages. Because
REST exposes data rather than methods, it gives developers the freedom to create new and innovative uses of the architecture.
However, because it is so open-ended, some amount of caution is needed in the design. Most important, a REST API should be
designed so that a GET request can never change the state of any resource in the system. Good REST API design protects against
accidental deletion or change by third-party applications or overzealous Web crawlers.
- Feedback