Testing secure endpoint using postman

Once our API is built, we need to provide a mechanism to document and test it quickly and without using a Web Debuggers such as Fiddler, Postman, etc. instead, we will use the Swagger UI specification – https://swagger.io/swagger-ui/

Swagger, to date, is a de facto standard as well as the web services and its WSDL in its day, as they define it in its web: “Swagger is the world’s largest framework of API developer tools for the OpenAPI Specification (OAS), enabling development across the entire API lifecycle, from design and documentation, to test and deployment. ”

To mention some advantages, here I leave:

Documentation effort saving of our APIs.
Portal for developers with all the info of our API to use it.
Describe each service and parameters of our API for developers
Automatic updating of documentation if there are changes in the definition of REST services.
Integrated Testing to test the services and their answers.
But as good Developers, we like to see things in action, so let’s set it up on our project, see how it works and understand how to document our REST APIs with hardly any effort.

Installing Swagger in our project

To include Swagger in our Web API project, we must install the Swashbuckle package through the NuGet package manager. Here as you like from the PM console or through the graphical interface, in our case, we will use the graphical interface to install version 5.6.0 of Swashbuckle and making sure that you are in the Browse tab.

Remember: It is also possible from the NuGet console with the command: PM> Install-Package Swashbuckle -Version 5.6.0

To confirm that it has been installed correctly, we will see a green icon in the graphical interface, a new class “SwaggerConfig.cs” in our Visual Studio solution and also update our packages.config as we see in the image.

In the package.config file we will see the new entries:

<package id="Swashbuckle" version="5.6.0" targetFramework="net461" /> <package id="Swashbuckle.Core" version="5.6.0" targetFramework="net461" />

We compile the project again to see that everything is correct and continue with the next step.

Configuring Swagger in our project

Once installed, we see that there is a new class “SwaggerConfig”, is responsible for the configuration of Swagger for our REST API, we will open it and leave it with the only minimal configuration to work. Then from here each one will have to configure according to their needs but for our example, this is enough:

We compile to ensure that there is no error and we are ready to test the documentation of our REST API.

Running the WebAPI Project

Now we just need to start the WebAPI project, if you remember the article part 2, when executing, we get an error 403 Forbidden, in fact, there is no need to worry because it is a configuration issue of IIS (you have the explanation in the previous article) and we ignore this message.

let’s navigate to localhost:49220/swagger and surprisingly we already have our documentation working.

Testing our WebAPI

It is crucial to load test your APIs to verify if your code is able to handle heaving loads of requests.

Remember calling an API to do authentication many times should not produce a new token each time, instead, your Auth service should have some logic in place to add expiry to your token whether it is a JWT token or a reference token.

In your test simply use the same token and load test your API, depending on token expiry you can renew the token when it is expired.

var client = new RestClient("http://yoursecureapi.com");
client.Authenticator = new HttpBasicAuthenticator(username, password);

var request = new RestRequest("resource/{id}", Method.GET);

// Add some header here maybe
request.AddHeader("header", "value");

// run the request as many times 
IRestResponse response = await client.ExecuteAsync(request);

And that is how you can test a secure API in Visual Studio unit test.

This is especially very handy when you don’t have any external load testing component in place.


We have seen how easy it is to include SwaggerUI to our REST API projects and how it allows us to easily generate the documentation and test our API with the web user interface that is available to us for free.

In addition, although we have not seen, you can easily customize the specification generated by XML from the Visual Studio itself and have a more detailed documentation if we want to offer a Developer Portal for external developers using our API and also extend the Swashbuckle component to customize it according to the needs of the project.

If you have questions or questions you can leave them in the comments.

Happy Coding!

You may also like...

2 Responses

  1. Derek says:

    well, wasn’t this quite obvious, could you write more about security? I feel the way you laid out this post needs more ink on how to actually secure it using bearer token.
    That’s the thing that would be more interesting to share.
    thanks anyways.

  2. pakzad says:

    You’re right Derek, I will take some time and write a blog post about authentication and authorization in general. Hopefully, that clears out some of the complications.

Leave a Reply

Your email address will not be published.