Is it REST? Does it matter? We have to test it anyway.
The Microsoft REST guidelines are being critiqued for not being particularly RESTful.
Pretty much every team I’ve worked on has had arguments about their implementation of REST APIs.
- Versioning?
- URI formats?
- Query strings or paths?
- Which return code?
- Support OPTION?
- Custom headers?
Those discussions are important for the design, but sometimes people get hung up on disagreements about theory.
The theory is important. We should read it, but at some point we have to make a decision about the implementation that works for us.
And at that point the theory almost doesn’t matter for testing. Testing deals with realities.
Reality - We could identify risks related to not interpreting REST in the same way as others:
- tools might be harder to use against our service
- libraries might not work as well against our service
- we might get hammered online
And as a team we might choose to experiment to mitigate the technical risk, and take it on the chin for the community risks.
Reality:
- Does it do what we want it to do?
- Does it do stuff we don’t want it to do?
To begin answering these questions we have learn how to interact with whatever the heck we have built, and however the heck we have built it.
And for most REST APIs this means:
- We need to understand some HTTP, JSON
- We need to know what HTTP verbs to use to interact with the API
- We need some tools to help us - I primarily use Postman and a proxy or two or three or more
- We need to practice on apps, so try: randomuser.me, getontracks VM1 VM2, redmine VM1 VM2
- and apichallenges
All of this means we have to do stuff. Learn the appropriate techniques, technologies and tools. And practice, practice, practice.
P.S. Our ‘Technical Web Testing 101’ course now includes “An Introduction to Interactive REST API Testing” this should provide a good introductory practical set of lectures and exercises to help people learn to interact with REST API - regardless of their RESTfulness or not.
