Testing Web Services

One of my roles with the Developer Network is to test and teach OCLC web services. While it isn't part of my job to do the regular testing of the services, there are some other things that go hand in hand with it that are: documentation and support for the services, building code examples and teaching people about the services. So when someone reports something as an problem, the first thing I do is try to replicate the issue. When my code isn't working, I fall back to making sure the service performs as anticipated. With RESTful read only services this is pretty simple. Here's what I do:

• Output the url I'm trying to access
• Put it in a web browser
• Look at the results

I do the same things when I teach. I walk through how to build a URL in a text editor. So that everyone can see all the parts and pieces.

Teaching and testing gets a lot more complicated when services perform content negotiation, because in order to adequately teach and test you need to send different Accept Headers as part of the request. While you can do this is Firefox with an extension called Modify Headers, this isn't how I like to do this. Why? Because this extension and JSONovitch which I use to view JSON don't mix well. (This is because they both are trying to change the Accept Headers Firefox is sending). Instead I often use CURL from the command line to do this basic type of testing. Sending a command like

curl -H "Accept: application/rdf+xml" -X GET http://viaf.org/viaf/75785466/

will make a request to VIAF and set the Accept Headers to application/rdf+xml . This will get me back a linked data representation of the authority I requested. If I set the verbose switch

curl -v -H "Accept: application/rdf+xml" -X GET http://viaf.org/viaf/75785466/

CURL will also allow me to see the headers sent back with the request. This includes information like the HTTP status, which will tell you if the request was successful or if it failed and in what way. Most of us who use the web are familiar with 404 messages which indicates a URL is "Not Found", but there are other useful messages like 403- Forbidden and 301 Permanently Moved.

Being able to set Accept Headers is just one piece of the puzzle though when testing services. Truly RESTful web services do write operations using the HTTP methods: PUT, POST, DELETE . To test these kinds of services you need to be able to specify the method. You can do this using CURL.

curl -X DELETE http://someurl.goes/here

But when you're doing PUT or POST you're often sending a file which adds to the complexity level. One way I handle this for testing is to write PHP code which performs the various methods. This is a good option if I'm testing and going to later write an application that uses these services. It gives me a template to refer back to and work from. But it is an inefficient way to deal with normal quick testing and completely useless for teaching purposes. So recently I started using REST Client which is a nice GUI client for doing this type of testing and teaching.

You can set the method, headers and the body (if you were sending a file). It also has the added advantage of allowing you to setup authentication: either Basic or Digest. You can also setup test scripts which is invaluable if you have to do lots of routine testing. I've been using it a bunch for the last week and it has save me a loads of time.

You can see a response retrieved using this to access VIAF below

I also have been using REST Client when I teach about RESTful services. It's easy to show people how to change the HTTP method from GET to (POST, PUT or DELETE) and how changing the Accept Headers will change the response you get. People understand quicker this way--because it allows them to see what is really going on.