Tools use to discover what API calls our applications are making

(Duong) #1

Hello,

I am a newbie in API testing, I am following 30 Days of API Testing challenge. The challenge 9th asks about sharing some tools we can use to discover what API calls our applications are making. However, I am not clear about the differences between a API testing tool and a tool uses to discover API calls. Could anyone give me explanations and example about the tool uses to discover API?

Thanks,
Duong

1 Like
30 Days of API Testing - Day 9: Share some tools we can use to discover what API calls our applications are making
30 Days of API Testing Day 8: Explore the API thread on The Club and contribute to the conversation
(David) #2

New to API testing, also on the same challenge as @oceannguyen!

What’s the difference between this and what something like fiddler does? It does show me POST, GET, etc. requests. You can send API requests as well, but it seems its main benefit is looking at them.

1 Like
(Ilya Lychkou) #3

I’m a newbie api testing too. I’m convinced that every tool has “primary” purpose (ex. Fiddler\Charles - capturing network traffic) as many software testing engineers usually use them in such a way and “other features” like composing requests (somebody use it but not so broad as “primary” one). Many tools have similar features. What tool to use, first of all, depends on what testing task you are performing at the current moment, not on type of testing.

1 Like
(Hilary) #4

I use a variety of tools to discover what API calls my application is making:

  • Fiddler/Charles/etc can show me what my app is calling directly
  • browser dev tools - Network tab can also show me what my app is calling directly
  • REST services can also have a Swagger or OpenAPI document available; SOAP services can have a WSDL - these tell you all kinds of things, and with Swagger/OpenAPI you can use them for manual testing as well
  • I can look at the code as well - Controllers tell me how my application handles API calls, and I can see what other code is using those controllers; Models tell me what data the API handles
7 Likes
(Duong) #5

Thank @dkotschessa, @ilya.lychkou and specially to @g33klady, your answers help me a lot in understand about the tools to discorver what API calls my application is making. I’m investigating how to use Fiddler as well as how to apply it to my work :blush:.

2 Likes
(Conor) #6

My thoughts are similar to Hillary(@g33klady)

Documentation: Read any available documention, tools such as swagger can help.
Source code: if possible get access to the source code through repo such as gitlab.

Using the documentation and source code you will know the status code, error messages etc.

Dev Tools: chrome dev tools is incrediblely useful. The network tab shows you all the activity of the API.
‪If you have no documentation or access to source code you can use your exploratory testing skills coupled with tools such as chrome dev tools and fiddler to figure out the API calls from the application.‬

Fiddler: web debugging proxy tool that can capture HTTP(S), as welll as help you test through useful option me such as the ability to throttle traffic.
Wireshark: Network Protocol analyzer
Command line: on Linux use commands such as tcpdump to see the network traffic on an interface.
Logging: Use any available logging tools to look for errors or perhaps sensitive information that should not be logged.
Tracing: use the output from tools such as zipkin for distributed tracing for micro services.

1 Like
(Darya ) #7

There are a lot of tools with an help you: Fidler, Charles and so on. But don’t forget DevTools, they can show a lot of information about your API

1 Like
(rosiecorn) #8

Good reads, Thank @g33klady for sharing

Beside Swagger, OpenAPI document
For Soap services, I recommend one tool call Wizdler, It is a chrome extension- everything you need just provides schema WSDL, then the tool will show all of the available APIs calls for your application.

(Jimmy) #9

I use JMeter and its recording feature and discovered what API calls it is making for our application that I didn’t know existed. It’s a very handy feature and already makes JMeter awesome as a potential many tools in one testing application.