Testing and Profiling ASP.NET Core REST API’s from Rider, part 1

There are many different ways to test Web API’s developed using ASP.NET Core. Let’s look at how we can cover testing and profiling our APIs inside Rider. We will be using the HTTP Client built into Rider’s IDE that will allow us to build the calls to our REST APIs developed in ASP.NET Core Web API.

In this first part of a two-part series, we will begin with creating and composing the scripts for our HTTP requests against an ASP.NET Core Web API solution. We will be testing the GET, POST, PUT and DELETE HTTP request verbs. In part two of the series, we will look at executing the HTTP requests and analyzing the responses.

In this series:

Creating HTTP Request Files

HTTP requests in Rider are done using a special, interactive file type that lets us craft and execute requests to a local or remote server.

There are two ways we can create an HTTP Request file: a scratch file or a physical file. Let’s look at the physical file first. Adding the file is just a right click on the project or folder and selecting Add | HTTP Request. Give the file a name and we will have our HTTP request file ready to be used after composing our request (discussed later in the post).

Rider HTTP Request Add Physical File

The other way we can work with HTTP Request files is by adding one to Scratches and Consoles. We can use the Ctrl+Shift+Alt+Insert shortcut to bring up the New Scratch File menu. Choose HTTP Request and a new scratch file will be created for us. In addition, we can right-click on Scratches and Consoles in Explorer to get the New Scratch File menu.

Rider HTTP Request Add Scratch File

We can also move HTTP request scratch files to physical files by use of refactoring.

Rider HTTP Request Move Scratch File

Composing Your HTTP Request File

Developing the logic for the HTTP Requests can be very elaborate. I will go into some of the basics to get you started writing your API calls. If you want to learn more in-depth about the HTTP Request in Editor specification that JetBrains has created you can check out this GitHub repo. We will look at creating a few scripts to call an ASP.NET Core Web API for the GET, POST, PUT and DELETE HTTP verbs.

To help with getting the scripts written for the HTTP requests, there are a number of live templates that will give you the start for the type of request you need. The following is an example of the GET verb template.

Rider HTTP Request GET Verb Scratch File

Let’s look at simple scripts for the four HTTP verbs that are used the most. The first is for retrieving all entities of a certain type from the Web API.

The following is the script to retrieve only a single entity of a type from the Web API being testing.

The next two scripts cover adding and updating an entity with the Web API. Both scripts show how we can send the json content for the entity that is being added and updated.

The last script covers the call for the DELETE verb used for deleting an entity. Just to let you know a secret: I don’t really delete the entity in the data repository. I like to deprecate the entity when using the DELETE verb.

Note that each script should end with ### to make sure that the results are saved to the log for historical purposes.

To learn more about writing the scripts for more advanced HTTP calls like multipart/form-data, please jump over to the Rider help for exploring the HTTP request in Editor syntax.

Download Rider 2018.3 and give it a try! We’d love to hear your feedback!

About Chris Woodruff

Chris Woodruff or Woody as his friends call him, is a Developer Advocate at JetBrains, working on .NET and Database tools. He focuses on .NET, REST APIs, web development, and AWS. Chris is a humbled speaker at various US and international conferences.
This entry was posted in How-To's and tagged , , , . Bookmark the permalink.

10 Responses to Testing and Profiling ASP.NET Core REST API’s from Rider, part 1

  1. Andrew says:

    Why would i choose this over swagger

    • Justin Trzebiatowski says:

      Or how about why this over Postman?

      • Kitty says:

        As long as you emit a swagger doc, postman, soapui, etc are all equally trivial to automate. Newman makes postman a little more compelling of late.

      • Chris Woodruff says:

        It is all about having choices and also having a strong experience inside the Rider IDE. I enjoy Postman for HTTP tests on API’s that I did not develop. Also, I like how I can store the HTTP Client files with my solution so they can be saved to source control.

    • Chris Woodruff says:

      I would say that our HTTP Client is not a substitute for Swagger but a way to test your API’s inside the Rider IDE. The biggest thing for us to have choices and to have the strongest IDE experience.

  2. Pingback: The Morning Brew - Chris Alcock » The Morning Brew #2700

  3. Pingback: Dew Drop – March 8, 2019 (#2915) | Morning Dew

  4. Anton says:

    What about remote debugging of .NET Core services inside docker with Rider?

    • Kitty says:

      Feels like add a volume to your dockerfile and dump log output is the option. I may have missed something, but it doesn’t seem presently integrated.

      • Anton says:

        I meant something more interactive. Like packaging vsdbg linux version into docker image and attaching from rider via socket/ssh

Leave a Reply

Your email address will not be published. Required fields are marked *