APIs Are Loose In The Wild: EuroSTAR 2020 Q & A

Questions

The following questions were raised by the attendees of the session at EuroSTAR:

1. Can you explain the difference between Authorization and Authentication?

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).

2. What is your perspective on Consumer-driven Contract Testing?

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.

3. Should functionality be tested in Automated API testing?

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.

4. What are the best tools to test API's?

That's a loaded question. However, I would recommend tools such as Rapise, Postman, SoupUI, and some others:

5. How to start learning API testing?

Check our whitepaper - "What is API Testing?".

6. How important is it to do Load Testing and Security Testing of the APIs as compared to Front End Load and Security tests?

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.

7. How to get API's for any mobile application, like if I am using a mobile App, is there any way I can find out what all API's that app is using ??

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.

8. Keeping old API versions could be a good idea. But it's still extra code and complexity. Developers would be against it. Any opinion on finding the right balance?

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.

9. What role does API testing have if your API is "only" an internal and not a public API?

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.

10. We have a cloud-native micro-service based application, and we do all automated tests via API calls. The UI testing we do is "decoupled" with a more focused UI testing framework. What do you think of this approach?

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.

One More Thing

If you would like to learn more about APIs and API Testing, please check out our whitepaper on API testing.