• Abstract and Figures
• Public Full-text

request to web api client download file c# Call a Web API From a .NET Client (C#) This content is for a previous version of .NET. New development should use ASP.NET Core. For more information on using ASP.NET Core Web API, see: This tutorial shows how to call a web API from a .NET application, using System.Net.Http.HttpClient. In this tutorial, a client app is written that consumes the following web API: Action HTTP method Relative URI Get a product by ID GET /api/products/ id Create a new product POST /api/products Update a product PUT /api/products/ id Delete a product DELETE /api/products/ id. To learn how to implement this API with ASP.NET Web API, see Creating a Web API that Supports CRUD Operations. For simplicity, the client application in this tutorial is a Windows console application. HttpClient is also supported for Windows Phone and Windows Store apps. For more information, see Writing Web API Client Code for Multiple Platforms Using Portable Libraries. NOTE: If you pass base URLs and relative URIs as hard-coded values, be mindful of the rules for utilizing the HttpClient API. The HttpClient.BaseAddress property should be set to an address with a trailing forward slash ( / ). For example, when passing hard-coded resource URIs to the HttpClient.GetAsync method, don't include a leading forward slash. To get a Product by ID: Set client.BaseAddress = new Uri("https://localhost:5001/"); Request a Product . For example, client.GetAsync<Product>("api/products/4"); . Create the Console Application. In Visual Studio, create a new Windows console app named HttpClientSample and paste in the following code: The preceding code is the complete client app. RunAsync runs and blocks until it completes. Most HttpClient methods are async, because they perform network I/O. All of the async tasks are done inside RunAsync . Normally an app doesn't block the main thread, but this app doesn't allow any interaction. Install the Web API Client Libraries. Use NuGet Package Manager to install the Web API Client Libraries package. From the Tools menu, select NuGet Package Manager > Package Manager Console . In the Package Manager Console (PMC), type the following command: The preceding command adds the following NuGet packages to the project: Microsoft.AspNet.WebApi.Client Newtonsoft.Json. Newtonsoft.Json (also known as Json.NET) is a popular high-performance JSON framework for .NET. Add a Model Class. Examine the Product class: This class matches the data model used by the web API. An app can use HttpClient to read a Product instance from an HTTP response. The app doesn't have to write any deserialization code. Create and Initialize HttpClient. Examine the static HttpClient property: HttpClient is intended to be instantiated once and reused throughout the life of an application. The following conditions can result in SocketException errors: Creating a new HttpClient instance per request. Server under heavy load. Creating a new HttpClient instance per request can exhaust the available sockets. The following code initializes the HttpClient instance: The preceding code: Sets the base URI for HTTP requests. Change the port number to the port used in the server app. The app won't work unless port for the server app is used. Sets the Accept header to "application/json". Setting this header tells the server to send data in JSON format. Send a GET request to retrieve a resource. The following code sends a GET request for a product: The GetAsync method sends the HTTP GET request. When the method completes, it returns an HttpResponseMessage that contains the HTTP response. If the status code in the response is a success code, the response body contains the JSON representation of a product. Call ReadAsAsync to deserialize the JSON payload to a Product instance. The ReadAsAsync method is asynchronous because the response body can be arbitrarily large. HttpClient does not throw an exception when the HTTP response contains an error code. Instead, the IsSuccessStatusCode property is false if the status is an error code. If you prefer to treat HTTP error codes as exceptions, call HttpResponseMessage.EnsureSuccessStatusCode on the response object. EnsureSuccessStatusCode throws an exception if the status code falls outside the range 200–299. Note that HttpClient can throw exceptions for other reasons — for example, if the request times out. Media-Type Formatters to Deserialize. When ReadAsAsync is called with no parameters, it uses a default set of media formatters to read the response body. The default formatters support JSON, XML, and Form-url-encoded data. Instead of using the default formatters, you can provide a list of formatters to the ReadAsAsync method. Using a list of formatters is useful if you have a custom media-type formatter: Sending a POST Request to Create a Resource. The following code sends a POST request that contains a Product instance in JSON format: The PostAsJsonAsync method: Serializes an object to JSON. Sends the JSON payload in a POST request. If the request succeeds: It should return a 201 (Created) response. The response should include the URL of the created resources in the Location header. Sending a PUT Request to Update a Resource. The following code sends a PUT request to update a product: The PutAsJsonAsync method works like PostAsJsonAsync , except that it sends a PUT request instead of POST. Sending a DELETE Request to Delete a Resource. The following code sends a DELETE request to delete a product: Like GET, a DELETE request does not have a request body. You don't need to specify JSON or XML format with DELETE. Test the sample. To test the client app: Download and run the server app. Download instructions. Verify the server app is working. For example, http://localhost:64195/api/products should return a list of products. Set the base URI for HTTP requests. Change the port number to the port used in the server app. Don’t write your Web API Client code — you’re wasting your precious time. Web APIs are heavily gaining traction in the software world, replacing the (good?) old Web Services. Virtually every API that is born today is likely to be REST and being built using frameworks like WCF (if you’re brave enough), ASP.NET MVC WebAPI or Spring. With this wide adoption of Web APIs, it’s important to provide the tools to make it efficient to work with these technologies. One particular case of efficiency is the ability to generate code whenever possible, in order to automate repetitive and no-brain-required tasks. Swagger is the new WSDL. If you’re old enough to remember Web Services, you’d know that W3C came up with the Web Service Description Language — or WSDL — which provides an XML-based description of the interface of the Web Service. WSDL is able to describe all the meta-data of a Web Service: operations, parameters, returns, complex objects, transaccional meta-data, etc. Although painful to be read by humans, WSDL has one awesome usage: Generating client code. Because REST APIs don’t come with such a description language, the community closed the gap and Swagger was born. Generating C# Web API Clients with NSwag. NSwag is an open source toolbox that, among other things, is able to generate C# and TypeScript client classes to consume Web APIs. It supports generating client code in the following scenarios: From ASP.NET Web API assembly by inspecting the assembly compiled by an ASP.NET Web API application or ASP.NET Core MVC; From Swagger specification either by reading the OpenAPI specification generated by Swagger or by generating it from the compiled assembly of the Web API; It also allows generating Open API specifications for ASP.NET Web API projects that do not use Swagger, which enables scenarios where users don’t want or can’t use Swagger. The documentation is very good and pretty extensive, but the following video is a good place to start: Using NSwag on a project. My test bed for NSwag was a small project I’m preparing for a training session, where I used NSwag to generate a C# Client for a Web API. Because the project is being built “as-we-go”, the interfaces of the Web API are subject to regular changes. So, I wanted to have simple way of re-generating the client code whenever the API contract was updated. Here’s the steps I took: Create a Class Library for your client code. I started by creating the Class Library that will receive the generated code and provide the client functionality. Pro tip: Always look to follow name conventions on your solutions. In this case, I named this Class Library with the suffix .Client to ensure that the purpose of this assembly is clear. For example, if your Web API project is named Foo.Bar.WebApi , the client assembly should be Foo.Bar.WebApi.Client . Creating .nswag project file. Then, I had to create my web-api-client.nswag file with NSwag Studio. This was pretty straight forward: Build the Solution to ensure the Web API DLLs are compiled; Select the .NET Assembly where the Web API Controllers are compiled into; Select which Controllers to generate client code from; On the “Outputs” pane, select the “CSharp Client” checkbox; Enter the namespace for the generated classes; At the end of the pane, enter the name of the file where client code will be generated — this file should in the directory of the .Client project; Click “Generate Files”; Et voila! The generated code for my beautiful Web API: Then I saved the .nswag file in the .Client Class Library and put it into source control, to make sure everyone is able to generate code using the same settings.

Load more

  7

Copy Link