Transcript
Testing RESTWeb Services
SOA Symposium Berlin 2010Jan Algermissen, algermissen@acm.org
Jan Algermissen
@algermissen
http://www.nordsc.com/
“Applying the Web to Enterprise IT”
MORE TO TEST THAN YOU THINK!
Client Server
Communication requires shared knowledge.
Client Server
Shared Knowledge Allows Expectations
Client Server
Expectation Levels
Expectation Levels
Message
Expectation Levels
Resource
Message
Expectation Levels
Application
Resource
Message
Expectation Levels
MESSAGE LEVEL FAULTS
GET /index.html HTTP/1.0
?
GET /index.html HTTP/1.0
HTTP/1.0 204 No Content/* Hello there */
DELETE /index.html HTTP/1.0
DELETE /index.html HTTP/1.0
HTTP/1.0 404.6 Verb deniedContent-Type: text/plain
Sorry, you cannot delete this resource.
?
GET /index.html HTTP/1.0
GET /index.html HTTP/1.0
HTTP/1.0 305 Use Proxy
?
HTTP 1.1(RFC 2616)
GET /news HTTP/1.0
GET /news HTTP/1.0
HTTP/1.0 200 OkContent-Type: application/atom+xml
<feed> <entry></fee>
?
GET /news HTTP/1.0
GET /news HTTP/1.0
HTTP/1.0 200 OkContent-Type: application/atom+xml
<feed> <link href=”/de/news” rel=”alternate” hreflang=”de”/> <link href=”/de/news2” rel=”alternate” hreflang=”de”/></feed>
?
MEDIA TYPE
TESTS
MessageLevel
•Correct HTTP syntax?•Correct HTTP semantics?•Correct payload syntax?•Correct payload semantics?
Message leveltests passed!
Are we done testing?
“The notion that REST-based user agents can't have expectations of a resource is clearly false.”
-- Roy Fielding
GREAT!MORE TO TEST
RESOURCE LEVEL FAULTS
GET /page.html HTTP/1.0
GET /page.html HTTP/1.0
200 OkContent-Type: text/html
<html> <body><p>My dog: <img src=”/img/dog.jpg”/> </p></body></html>
GET /img/dog.jpg HTTP/1.0Accept: image/*
GET /img/dog.jpg HTTP/1.0Accept: image/*
HTTP/1.0 406 Not AcceptableContent-Length: 0
Link semantics create expectations.
<html><head> <link rel=”stylesheet” type=”text/css” href=”/css/default.css”/> </head>....</html>
“A stylesheet”
<app:collection href=”/blog/entries”> <app:accept>text/plain</app:accept></app:collection>
“A collection”
<OpenSearchDescription> <Url type=”application/rss+xml” template=”/search?q={searchTerms}”/></OpenSearchDescription>
“A search result”
Link semantics create expectations.
These expectations can be tested.
BUT HOW?
Specifications (loosely) associate link semantics
with media types.
curl -I http://foo.org/img/dog.jpg -HAccept:image/*
HTTP/1.1 406 Not AcceptableContent-Length: 0
Verify that it is an image
406 —› Test failed
curl -I http://foo.org/blog/entries \ -HAccept:application/atom+xml
HTTP/1.1 200 OkContent-Type: application/atom+xml
Verify that it is a collection
200 —› Test passed
Use media types to test resource
semantics
GET /articles/1002110.html HTTP/1.0
GET /articles/1002110.html HTTP/1.0
HTTP/1.0 200 OkDate: Tue, 2 Jun 2010 11:00:00 GMTContent-Type: text/html
<html>...</html>
GET /articles/1002110.html HTTP/1.0
GET /articles/1002110.html HTTP/1.0
HTTP/1.0 404 Not FoundDate: Wed, 3 Jun 2010 11:00:00 GMTContent-Type: text/plain
Nothing found that matches the request URI.
?
GET /stock-quote/COKE HTTP/1.0
GET /stock-quote/COKE HTTP/1.0
HTTP/1.0 200 OkDate: Tue, 2 Jun 2010 11:00:00 GMTContent-Type: text/plain
49.5
GET /stock-quote/COKE HTTP/1.0
GET /stock-quote/COKE HTTP/1.0
HTTP/1.0 200 OkDate: Wed, 3 Jun 2010 11:00:00 GMTContent-Type: text/plain
Current weather in Berlin: 25 degrees Celsius, sunny.
?
Cool URIs don’t change!
GET /orders/42 HTTP/1.0Accept: application/order
GET /orders/42 HTTP/1.0Accept: application/order
HTTP/1.0 200 OkDate: Tue, 2 Jun 2010 11:00:00 GMTContent-Type: application/order
<order> ... </order>
GET /orders/42 HTTP/1.0Accept: application/order
GET /orders/42 HTTP/1.0Accept: application/order
HTTP/1.0 406 Not AcceptableDate: Wed, 3 Jun 2010 11:00:00 GMTContent-Type: text/plain
Media type application/order no longer available. Try application/order.v2
?
BE NICE!
Keep variants around.
TESTS
ResourceLevel
•Does resource match link semantics?•Is resource available over time?•Are resource semantics stable over time?•Are variants available over time?
APPLICATION LEVEL FAULTS
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
GET /shop-home.html HTTP/1.0Host: www.bestbookshop.com
GET /shop-home.html HTTP/1.0Host: www.bestbookshop.com
HTTP/1.0 200 OkContent-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>
?
Application Level Tests
Does the service workas expected by the application?
Application Level Tests
Does the service workas expected by the application?
Testable only in context of the application. The server cannot know how it is being re-used!
TESTS
ApplicationLevel
•Does service offer expected capability?•Is the user goal reachable?
Testing REST Web Services
Testing REST Web Services
MessageLevel
•Correct HTTP syntax?•Correct HTTP semantics?•Correct payload syntax?•Correct payload semantics?
ResourceLevel
•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
MessageLevel
•Correct HTTP syntax?•Correct HTTP semantics?•Correct payload syntax?•Correct payload semantics?
ResourceLevel
•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
ApplicationLevel
•Does service offer expected capability?•Is the user goal reachable?
MessageLevel
•Correct HTTP syntax?•Correct HTTP semantics?•Correct payload syntax?•Correct payload semantics?
EXPLORE THECONTRACT
SERVER MUST PASS TESTS
SERVER MUST PASS TESTS
NO CLIENT ASSUMPTIONS BEYOND TESTS
USETESTS ASGUIDE
Server Developer Client Developer
Server Developer Guidance
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
Anything else is not constrained and will
not break clients!
Server may....
•Change representations•Add resources•Add variants•Make full use of HTTP•Make full use of media types
Client Developer Guidance
Client may rely on...
•Message level correctness•Resources matching link semantics•Bookmarkable URIs•Stable resource semantics•Variant availability over time•Stable service nature
Anything else the server is absolutely
free to change at any time.
The client must...
•Implement all of HTTP•Deal with supported media types
completely•Prepare for unexpected but valid
responses
Take Aways
•Quite some things to test•Tests reveal and illustrate contract•REST constrains over time•Servers are, in fact, rather constrained
REST achieves evolvability by
rigorous constraints on server change!
HAPPY TESTING!
top related