Strongly Typed Client API Generators generate strongly typed client API in C# codes and TypeScript codes. You may then provide or publish either the generated source codes or the compiled client API libraries to other developers for developing client programs.

This project delivers these products:

1. Code generator for strongly typed client API in C# supporting .NET Framework, .NET Core and Xamarin.Forms.
2. Code generators for strongly typed client API in TypeScript for jQuery, Angular 2, Aurelia, Axios and Fetch API.
3. TypeScript CodeDOM, a CodeDOM component for TypeScript, derived from CodeDOM of .NET Framework.
4. POCO2TS.exe, a command line program that generates TypeScript interfaces from POCO classes.
5. Fonlow.Poco2Ts, a component that generates TypeScript interfaces from POCO classes.

Hints:

• The packages could be used independently as long as the usages conform to the dependencies.
• OpenApiClientGen based on key components of WebApiClientGen is a spin-off for generating client API codes in C# and TypeScript according to a definition file of Swagger/Open API Specification.

1. Client API codes generated are directly mapped from the Web API controller methods, .NET primitive types and POCO classes. This is similar to what svcutil.exe in WCF has offered.
2. Doc comments of controller methods and POCO classes are copied.

1. WebApiClientGen is seamlessly integrated with ASP.NET Web API with very little steps/overheads to setup, maintain and synchronize between Web API and client APIs, during RAD or Agile Software Development.
2. Support all .NET primitive types including decimal.
3. Support DataTime, DataTimeOffset, Array, Tuple, Dynamic Object, Dictionary and KeyValuePair
4. Strongly typed generated codes are subject to design time type checking and compile time type checking.
5. Provide high level of abstraction, shielding application developers from repetitive technical details of RESTful practices and traditional AJAX calls.
6. Rich meta info including doc comments make IDE intellisense more helpful, so application developers have less need of reading separated API documents.

1. POCO classes
2. Web API
3. Generated client API C# codes
4. Client codes using the generated library in C#
5. Generated client data models and API in TypeScript for jQuery, for Angular 2, for Aurelia and for Axios
6. Client codes using the generated library in TypeScript

Remarks:

1. JavaScript codes compiled from generated TypeScript codes could be used in JS applications, however, obviously no type info will be available, while application programmers may still enjoy intellisense and abstraction from AJAX details.
2. React and Vue.js applications typically use Axios for HTTP requests. Currently babel does not support namespaces. So you may not do React TSX programming with generated TypeScript codes. However, this may be changed in near future because of this pull request.

1. Strongly Typed Client API Generators for ASP.NET Web API
2. TypeScript CodeDOM
3. POCO2TS.exe
4. Fonlow.Poco2TS

1. jQuery and HttpClient helper library
2. Angular 6+
3. AXIOS
4. Aurelia
5. Fetch API

1. Strongly Typed Client API Generators for ASP.NET Core Web API.
2. TypeScript CodeDOM
3. Fonlow.Poco2TS

1. jQuery and HttpClient helper library
2. Angular 6+
3. AXIOS
4. Aurelia
5. Fetch API

1. Web API vendors / developers should provide client API libraries to developers of client programs, as Google and Amazon etc. would do in order to make the RESTful Web API reach wider consumers (internal and external) efficiently.
2. To client developers, classic function prototypes like ReturnType DoSomething(Type1 t1, Type2 t2 ...) is the API function, and the rest is the technical implementation details of transportations: TCP/IP, HTTP, SOAP, resource-oriented, CRUD-based URIs, RESTful, XML and JSON etc. The function prototype and a piece of API document should be good enough for calling the API function.
3. The better you have separation of concerns in your Web API design, the more you will benefit from the components of this project in order to deliver business values sooner, with less handcrafted codes , less repetitive tasks and less chances of human mistakes.

Server side:

1. .NET Framework 4.6.2, or .NET Core 3.1
2. ASP.NET Web API 2.2, or ASP.NET Core 3.1

Remarks:

• WebApiClientGenCore v3.5 supports .NET Core 3.1. If your .NET Core API projects are still with .NET Core 2.0/2.1/2.2/3.0, please use previous releases.
• .NET Core 2.x had dependency on Newtonsoft.JSON, while .NET Core 3.0 had been decoupled from Neewtonsoft.JSON and the default serializer is working well in most scenarios except for Tuple, 2D array and anonymous object etc. If you would support these data types or would keep 100% compitability with the serialization of NewtonSoft.JSON, you should explicitly include package Microsoft.AspNetCore.Mvc.NewtonsoftJson and add add AddNewtonsoftJson() in Startup.cs.
• WebApiClientGen v3.0 supports .NET Framework 4.6.2. If your Web API projects are still with .NET Framework 4.5.2, please use previous releases.

.NET client side:

1. .NET Framework 4.5.2, or Universal Windows, or Mono.Android, or Xamarin.iOS, or .NET Core 2.0/2.1
2. ASP.NET Web API 2.2 Client Libraries
3. Json.NET of Newtonsoft for Content-Type application/json
4. Microsoft Build Tools 2015

TypeScript client side:

1. TypeScript compiler
2. jQuery
3. Angular 2-9
4. Aurelia
5. Axios
6. Fetch API

For more details, please check WIKI, and codeproject.com articles at:

1. Generate C# .NET Client API for ASP.NET Web API
2. Generate TypeScript Client API for ASP.NET Web API
3. ASP.NET Web API, Angular2, TypeScript and WebApiClientGen
4. Generate C# Client API for ASP.NET Core Web API

The Demo applications in this repository are mainly for testing WebApiClientGen during development. And there are other demo applications in the following repositories, demostrating how real world applications could utilize WebApiClientGen:

1. WebApiClientGen Examples
2. .NET Core Demo
3. WebApiClientGen vs Swagger

These demo applications are actively maintained and kept up-to-date with the latest frameworks. If you are still staying with some older frameworks like Angular 4 or 5 or .NET Core 2.0, you may navigate to respective tags of the repositories and checkout.