středa 9. listopadu 2011

Is it possible to automatically test REST constraints?

In this post, I am going to look at testability of REST constraints. What interests me most is if we can test them one by one automatically? Are we able to write bot, program or some test framework which can tell "yes, your api is/isn't RESTful"? I am going to focus on REST constraints implemented on HTTP protocol.

You can take look at the constraints of REST and what benefits they brings at my previous post.

Constraints we can test automatically:

Cache constraint can be checked by looking at HTTP headers Cache-Control, Expires, Last-Modified. For fulfillment of this constraint, every response from server should contain them.
There is actually an online tool - redbot which analyzes the headers and tells about cacheability (among other things).


Constraints we maybe can test automatically:

Client-Server - HTTP itself is client-server. But we should somehow test if server just listens and wait for requests. My proposal: if we obtain a response after our client send request is it satisfying to tell this constraint is met?

Uniform Interface - my proposal: if this condition is met, the generic client should be able to go through all server's services (from one starting point) and used them without any special client's implementation. The client should only use standardized methods with communicating with server. 


Constraints we don't know how to test automatically:

Null style - we would have to test if some of "all other constraint" isn't present in the app. That's pretty huge number of tests ;-)

Stateless -  the programmer of the server can probably tell if it is stateless but if the server is black box for us, how to test if it keeps some state? Perhaps we can send same requests in a row and assume we always get same answer?

Layered System - the programmer of the server can probably tell if his system is layered, but how can we test it if server is black box for us?

Code-On-Demand - just optional constraint and again, the server programmer can tell if the server is capable of that.


Conclusion:

We can test one condition. We maybe can test another two. We cannot test another four but three of that four can be answered by programmer of server.

Žádné komentáře:

Okomentovat