Home

Getting Started

Presumptions

1. You are developing ASP.NET Web API 2.x applications, and the client programs of the APIs include Windows desktop applications and Windows store apps, in addition to the Web front end based on AJAX.
2. Many of the API functions are to transport DTO in content type application/json or application/xml.
3. You and fellow developer prefer highly abstraction through strongly typed functions in both the server side and the client side.
4. You expect that the client API generated has the same level of abstraction and strongly typed functions like those generated by SvcUtil.exe in WCF.
5. The POCO classes are used by both Web API and Entity Framework Code First, and you may not want to publish all data members to client programs.

Optional Presumptions

This component set was designed for big projects with large amount of complex data models and rich Web API, thus certain engineering best practices are expected.

1. You have some experiences in developing or consuming SOAP Web services through WCF, and you know about DataCotractAttribute.
2. Your Web application is big enough so you would put most if not all data models (POCO classes) into 1 or 2 dedicated assemblies besides the MVC or Web API assembly.
3. You would use data annotations for defining DTO (Data Transfer Object) from existing data model classes.

Hints: Even if your design does not fall into the optional presumptions, for example, having all classes into the MVC/Web API project, you may still use this component set well.

What's Not

In these scenarios, the code generators may not be for you:

1. Your Web API is for AJAX Web applications which do not use TypeScript during development, even though the javascript files compiled from the generated TypeScript codes are usable in traditional Javascript development.
2. You bill through LoC or hours and you don't mind doing repetitive tasks of constructing client codes.
3. Your Web API functions are not strongly typed in the function prototypes, for example dealing with only IHttpActionResult, documents and stream.
4. You want the client programming cares more about or take advantages of REST or "Hypermedia as The Engine of Application State" (HATEOAS) because your domains may be better to be presented as resources and states.

Remarks: Even if you decide to go the HATEOAS path, the POCO2TS application may generate TypeScript interfaces to describe the data models. Including TypeScript interfaces may help the consumers of your HAL services.

For more details, please check DOCUMENTATION.