Testing REST Web Services at DEVOXX 2010

Editor's Notes

1. Welcome.
2. My name is Jan Algermissen. I am working as a software architect and consultant focussing on Enterprise REST. On solving classic enterprise IT problems with Web architecture. Contact Information on Intro slide. If you asked me, how well REST and the Enterprise fit together it comes as now surprise that to me personally they a re a perfect couple. <click>
3. There you have it - pure harmony. However I also think that a number of aspects of REST need more explanation to make the whole concept suitable for Enterprise development. To me, one of these aspects is testing so this is the basic motivation behind this talk. Agenda: 1. Look at contract between client and server that exists in RESTful systems 2. Explore expectations made by clients 3. Introduce a method for testing. Q. Who knows what REST is? Who has created enterprise production systems that use REST? Have you developed a dedicated testing process? And who is only here to learn about REST? I like to start out with a rather bold statement:
4. The precondition for testing is having a contract. Contract is the basis for expectations. Expectations is what we are going to test. Let’s explore the contract.
5. RPC Style integration. Every provider has a special contract the consumer has to understand (implement). This leads to undesirable coupling and eventually makes evolving the system very difficult. One of the primary design goals of REST is to improve this situation.
6. REST eliminates all service specific contract. Moves it to a global space. E.g. IANA, in case of the World Wide Web. Consequence is that there are no service specific contracts anymore and therefore no coupling between individual clients and servers. REST eliminates all service descriptions.
7. No idl, no wsdl, no wadl, not even html because there is nothing to describe.
8. No idl, no wsdl, no wadl, not even html because there is nothing to describe.
9. No idl, no wsdl, no wadl, not even html because there is nothing to describe.
10. No idl, no wsdl, no wadl, not even html because there is nothing to describe.
12. So then - how and what to test. And what is informing the client developer about what she is allowed to do? Does this mean that a server developer can basically do *anything*? Let’s look at expectations once more. Since communication exists between client and server there surely is some shared knowledge. Based on that knowledge the client makes assumptions about the server.
20. Is that right? Did some digging through the mailing lists and came up with the following interesting quote:
21. Where do these expectations come from? First, the server is telling us something about the resources!
25. Another source to learn about expectations about resources is Tim Berners Lee’s classic Web design article: “Cool URIs Don’t change”.
98. Testing process running over time. Accumulating information in turn used for testing. Continuous operation or explicit activation.
103. Questions?