Http files are nice and handy - but they are also a bit of a pain to update. So why not generate them from a swagger definition?
HTTP file
When you create a new Web API with .net 8, you get a MyProjectName.http file. It looks something like this:
@MyWebApp_HostAddress = http://localhost:5059
GET {{MyWebApp_HostAddress}}/weatherforecast/
Accept: application/json
###
This file is used by the REST Client extension in Visual Studio Code, Visual Studio and Rider. It allows you to send HTTP requests to your API directly from the editor. That is very handy when you are developing your API. Of course you can always use Postman, curl or your swagger UI - but this is just so much easier.
But there is a big problem: Updating those can be a pain. So imagine we add the following two new endpoints to our API:
app.MapPost("/weatherforecast", (CreateWeatherDto dto) => TypedResults.Ok())
.WithName("CreateWeatherForecast")
.WithOpenApi();
app.MapDelete("/weatherforecast/{id}", (int id) => TypedResults.Ok())
.WithName("DeleteWeatherForecast")
.WithOpenApi();
To make that automatically for us, we can utilize a nice dotnet global tool: httpgenerator.
The setup is trivial, just run dotnet tool install --global httpgenerator and you are good to go!
Now imagine you did run you server, you can use the tool like this:
httpgenerator http://localhost:5059/swagger/v1/swagger.json --output-type OneFile
The --output-type OneFile will merge all endpoints into one file, otherwise you receive n files for each endpoint - which is not very handy.
The file will always be called Requests.http and will be placed in the current directory (if not specified otherwise via the --output toggle). So you might want to renmae the file to MyProjectName.http to match the naming convention. Anyway this is the result:
@contentType = application/json
###################################
### Request: GET /weatherforecast
###################################
GET http://localhost:5059/weatherforecast
Content-Type: {{contentType}}
####################################
### Request: POST /weatherforecast
####################################
POST http://localhost:5059/weatherforecast
Content-Type: {{contentType}}
{
"temperatureC": 0,
"summary": "summary"
}
###########################################
### Request: DELETE /weatherforecast/{id}
###########################################
M
### Path Parameter: DeleteWeatherForecast_id
@DeleteWeatherForecast_id = 0
DELETE http://localhost:5059/weatherforecast/{{DeleteWeatherForecast_id}}
Content-Type: {{contentType}}
Exactly what I did expect. The tool also supports providing Bearer tokens, which is very handy for testing protected endpoints. Just checkout the GitHub page for more information.
