Pretty much every team I’ve worked on has had arguments about their implementation of REST APIs.
- URI formats?
- Query strings or paths?
- Which return code?
- Support OPTION?
- Custom headers?
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
- Does it do what we want it to do?
- Does it do stuff we don’t want it to do?
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 or even RestMud
P.S. Our $10 ’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.