Testing REST Web Services
3 likes1,677 views
This document discusses testing REST web services at three levels: message level, resource level, and application level. At the message level, tests check for correct HTTP syntax, semantics, and payload syntax and semantics. At the resource level, tests check if resources match link semantics, are available over time, have stable semantics over time, and maintain variants. At the application level, tests check if the service offers expected capabilities and if the user's goal is reachable. The document provides guidance for both server and client developers, noting what each can rely on and what each must implement to ensure the service under test conforms to the constraints of REST.
Testing REST Web Services
- 1. Testing REST Web Services SOA Symposium Berlin 2010 Jan Algermissen, [email protected]
- 2. Jan Algermissen @algermissen http://www.nordsc.com/ “Applying the Web to Enterprise IT”
- 3. MORE TO TEST THAN YOU THINK!
- 4. Client Server Communication requires shared knowledge.
- 5. Client Server Shared Knowledge Allows Expectations
- 13. ? GET /index.html HTTP/1.0 HTTP/1.0 204 No Content /* Hello there */
- 15. DELETE /index.html HTTP/1.0 HTTP/1.0 404.6 Verb denied Content-Type: text/plain Sorry, you cannot delete this resource. ?
- 17. GET /index.html HTTP/1.0 HTTP/1.0 305 Use Proxy ?
- 20. GET /news HTTP/1.0 HTTP/1.0 200 Ok Content-Type: application/atom+xml <feed> <entry> </fee> ?
- 22. GET /news HTTP/1.0 HTTP/1.0 200 Ok Content-Type: application/atom+xml <feed> <link href=”/de/news” rel=”alternate” hreflang=”de”/> <link href=”/de/news2” rel=”alternate” hreflang=”de”/> </feed> ?
- 23. MEDIA TYPE
- 24. TESTS Message Level •Correct HTTP syntax? •Correct HTTP semantics? •Correct payload syntax? •Correct payload semantics?
- 25. Message level tests passed! Are we done testing?
- 26. “The notion that REST-based user agents can't have expectations of a resource is clearly false.” -- Roy Fielding
- 30. GET /page.html HTTP/1.0 200 Ok Content-Type: text/html <html> <body><p>My dog: <img src=”/img/dog.jpg”/> </p></body> </html>
- 31. GET /img/dog.jpg HTTP/1.0 Accept: image/*
- 32. GET /img/dog.jpg HTTP/1.0 Accept: image/* HTTP/1.0 406 Not Acceptable Content-Length: 0
- 34. <html><head> <link rel=”stylesheet” type=”text/css” href=”/css/default.css”/> </head> .... </html> “A stylesheet”
- 37. Link semantics create expectations. These expectations can be tested.
- 38. BUT HOW?
- 39. Specifications (loosely) associate link semantics with media types.
- 40. curl -I http://foo.org/img/dog.jpg -HAccept:image/* HTTP/1.1 406 Not Acceptable Content-Length: 0 Verify that it is an image 406 —› Test failed
- 41. curl -I http://foo.org/blog/entries -HAccept:application/atom+xml HTTP/1.1 200 Ok Content-Type: application/atom+xml Verify that it is a collection 200 —› Test passed
- 42. Use media types to test resource semantics
- 44. GET /articles/1002110.html HTTP/1.0 HTTP/1.0 200 Ok Date: Tue, 2 Jun 2010 11:00:00 GMT Content-Type: text/html <html>...</html>
- 46. GET /articles/1002110.html HTTP/1.0 HTTP/1.0 404 Not Found Date: Wed, 3 Jun 2010 11:00:00 GMT Content-Type: text/plain Nothing found that matches the request URI. ?
- 48. GET /stock-quote/COKE HTTP/1.0 HTTP/1.0 200 Ok Date: Tue, 2 Jun 2010 11:00:00 GMT Content-Type: text/plain 49.5
- 50. GET /stock-quote/COKE HTTP/1.0 HTTP/1.0 200 Ok Date: Wed, 3 Jun 2010 11:00:00 GMT Content-Type: text/plain Current weather in Berlin: 25 degrees Celsius, sunny. ?
- 51. Cool URIs don’t change!
- 52. GET /orders/42 HTTP/1.0 Accept: application/order
- 53. GET /orders/42 HTTP/1.0 Accept: application/order HTTP/1.0 200 Ok Date: Tue, 2 Jun 2010 11:00:00 GMT Content-Type: application/order <order> ... </order>
- 54. GET /orders/42 HTTP/1.0 Accept: application/order
- 55. GET /orders/42 HTTP/1.0 Accept: application/order HTTP/1.0 406 Not Acceptable Date: Wed, 3 Jun 2010 11:00:00 GMT Content-Type: text/plain Media type application/order no longer available. Try application/order.v2 ?
- 56. BE NICE! Keep variants around.
- 57. TESTS Resource Level •Does resource match link semantics? •Is resource available over time? •Are resource semantics stable over time? •Are variants available over time?
- 59. What’s an application anyway? •Buying a book in an online store •Looking up a word in an online dictionary •Taking an online exam •Indexing a set of Web sites •Checking for updates in monitored feeds •Monitoring programming language adoption using stackoverflow.com
- 60. GET /shop-home.html HTTP/1.0 Host: www.bestbookshop.com
- 61. GET /shop-home.html HTTP/1.0 Host: www.bestbookshop.com HTTP/1.0 200 Ok Content-Type: text/html <html><body><p> Sorry, buying is not possible here anymore. Check out the store catalog at <a href=”/ catalog.html”/> and walk to one of our stores. </p></body></html> ?
- 62. Application Level Tests Does the service work as expected by the application?
- 63. Application Level Tests Does the service work as expected by the application? Testable only in context of the application. The server cannot know how it is being re-used!
- 64. TESTS Application Level •Does service offer expected capability? •Is the user goal reachable?
- 65. Testing REST Web Services
- 66. Testing REST Web Services Message Level •Correct HTTP syntax? •Correct HTTP semantics? •Correct payload syntax? •Correct payload semantics?
- 67. Resource Level •Does resource match link semantics? •Is resource available over time? •Are resource semantics stable over time? •Are variants available over time? Testing REST Web Services Message Level •Correct HTTP syntax? •Correct HTTP semantics? •Correct payload syntax? •Correct payload semantics?
- 68. Resource Level •Does resource match link semantics? •Is resource available over time? •Are resource semantics stable over time? •Are variants available over time? Testing REST Web Services Application Level •Does service offer expected capability? •Is the user goal reachable? Message Level •Correct HTTP syntax? •Correct HTTP semantics? •Correct payload syntax? •Correct payload semantics?
- 70. SERVER MUST PASS TESTS
- 71. SERVER MUST PASS TESTS NO CLIENT ASSUMPTIONS BEYOND TESTS
- 72. USE TESTS AS GUIDE Server Developer Client Developer
- 74. Server must... •Conform to HTTP •Conform to the media types used •Resources must match link semantics •Keep URIs around •Keep resource semantics stable •Maintain variants over time •Maintain capabilities
- 75. Anything else is not constrained and will not break clients!
- 76. Server may.... •Change representations •Add resources •Add variants •Make full use of HTTP •Make full use of media types
- 78. Client may rely on... •Message level correctness •Resources matching link semantics •Bookmarkable URIs •Stable resource semantics •Variant availability over time •Stable service nature
- 79. Anything else the server is absolutely free to change at any time.
- 80. The client must... •Implement all of HTTP •Deal with supported media types completely •Prepare for unexpected but valid responses
- 81. Take Aways •Quite some things to test •Tests reveal and illustrate contract •REST constrains over time •Servers are, in fact, rather constrained
- 82. REST achieves evolvability by rigorous constraints on server change!
- 83. HAPPY TESTING!