Testing REST Web Services

Testing RESTWeb Services

SOA Symposium Berlin 2010Jan Algermissen, [email protected]

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

?


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.

?


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


<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


Verify that it is a collection

200 —› Test passed

Use media types to test resource

semantics

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>


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


HTTP/1.0 200 OkDate: Tue, 2 Jun 2010 11:00:00 GMTContent-Type: text/plain

49.5


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


HTTP/1.0 200 OkDate: Tue, 2 Jun 2010 11:00:00 GMTContent-Type: application/order

<order> ... </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


MessageLevel


ResourceLevel



MessageLevel


ResourceLevel



ApplicationLevel

•Does service offer expected capability?•Is the user goal reachable?

MessageLevel


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!

Testing REST Web Services

Documents

Transcript of Testing REST Web Services