December 8th, 2020 by inflectra
During the recent EuroSTAR 2020 Virtual Conference, Adam Sandman, Director of Technology at Inflectra presented a session on Testing APIs in the Wild. During this talk, there were many questions from the attendees, but unfortunately during the session, there was only time to answer a few of them. In this blog, Adam covers some of the remaining questions.
The following questions were raised by the attendees of the session at EuroSTAR:
Authentication is the checking that a user is who they say they are, i.e., are they a valid user of the system. For APIs that is done using one of many possible authentication methods such as using a login and password (basic authentication), using a trusted protocol such as OAuth, a secure certificate, a valid session cookie, or some other method that guarantees that a user is real and valid to access the system (e.g., biometrics, retina scans, etc.)
On the other hand, authorization is the checking that a user who is already authenticated has access to perform a specific operation. For APIs, that usually means that the user is allowed to call the specific API endpoint with the specific method (GET, POST, PUT, etc.), and the data passed in affects the part of the system the user has access to (e.g., a valid account number for that user).
I am a big proponent of maintaining guaranteed interfaces for APIs so that once you release a set of API endpoints, you don't keep breaking compatibility and requiring the clients to have to change their code. To me, that is simply a failure in API design. One solution is to have the clients propose the Contracts and have the testers create their API tests based on these contracts (consumer-driven contract testing). However, I think the most important thing is that testers get the contracts and write automated tests against those, and refuse to change them just because the developers want to.
So alternatives to having the contracts be consumer-driven would be to have a set of versioned APIs instead. That way, when customers have new requests, you can add new versions and still maintain the old versions for backward compatibility. That is my preference, to be honest.
Absolutely, I would recommend that you potentially combine API testing with UI testing so that you can load in data through the API and then check that it appears in the application correctly. You could use an automated UI tool such as Selenium to do this. However, Rapise from Inflectra can do both API and UI testing in the same test.
That's a loaded question. However, I would recommend tools such as Rapise, Postman, SoupUI, and some others:
Check our whitepaper - "What is API Testing?".
I have a whole separate presentation about load testing and security testing of APIs, come to a future talk, and I'll be happy to share that with you.
However, in a nutshell, when you have APIs, you don't want to end up with a data breach because they are insecure, especially since they are easier to hack than a UI because they are so automatable. Also, for performance, if your API goes down, you may hobble hundreds of other websites and customers, which is potentially worse than if just one application is unavailable.
That is a good question, assuming you are referring to REST APIs that are being called by the native app, then you can use tools like Fiddler to spy on the network traffic from the mobile application. Unlike a browser where you can just click F12 and use the Network tab to see the HTTP/HTTPS requests and inspect the payload, you will need to use a proxy to redirect the traffic and allow you to inspect what is sent to/from the mobile app and the server. There is a good article on Medium about this approach.
I agree there is a trade-off, but with good automated tests, it's not so bad. I would make your developers rewrite every plugin that needs to be changed if you don't maintain an old version, that for us, has been a very good incentive. SpiraTeam, our flagship tool, has APIs that go back 15 years.
It still has an important function because otherwise, the systems connecting to your API may fail and not be detected. However, you could limit your testing to more 'happy path' cases, and you wouldn't need to worry about compatibility and contracts, so you could only have one version of the API to test. That way, the API could change, and you just update the tests and consuming applications in-house.
It makes sense; however, I think there could be value in testing that API calls result in the valid data being displayed in the UI and vice versa.
If you would like to learn more about APIs and API Testing, please check out our whitepaper on API testing.