Skip to content

WebApiProxy v.s. WebApiClientGen

Jump to bottom
fonlow edited this page Jun 5, 2017 · 1 revision

Among alternative solutions of generating client codes, WebApiProxy is the most similar to WebApiClientGen.

  1. What similar

  2. Both products provide C# client proxy classes upon RESTful Web service developed through ASP.NET Web API Framework.

  3. The designs take advantage of the info exposed by ApiExplorer in order to provide semantically meaningful function names and class names to the client sides, provided the API controllers follow good naming conventions.

  4. The client programmers may get nice intellisense and hints with the proxy classes when writing client codes.

  5. What different in design

WebApiProxy's server side library generates meta data according to ApiExplorer at runtime; and the client side library in the client project may then use the meta data and the T4 templates to generate code snippets in IDE.

WebApiClientGen reads ApiExplorer at runtime and generate strongly typed client codes directly through CodeGenController which is available in debug build. Such design is based on the concept that the client library should be generated only once for each release (with breaking changes in interfaces) of Web API. And the client program will use a generated client API library.

WebApiProxy supports generated javascript proxy. However, javascript is not a strongly typed language, so WebApiClientGen won't have javascript in the scope.

  1. What different in usage

This video illustrates the usage of WebApiProxy well.

With WebApiProxy, a client program has dependency on WebApiProxy.Core.dll and WebApiProxy.Tasks.dll, and you get rid of the need of writing codes for binding data to URL queries, while you still need to parse http response.

With WebApiClientGen, the client function prototypes generated are almost identical to the function prototypes of the Web API, and a client program has dependency on the generated client API library like DemoWebApi.Client.dll. So you client codes could be much shorter, and you get less chances of making mistakes.

WebApiClientGen encourages only 1 instance of HttpClient in a client program, and there's no need to frequently dispose HttpClient instances. An instance of HttpClient may be consider as a Web browser but without UI.

Limitation of WebApiProxy

  1. The client proxy functions generated are not really strongly typed, and you as a client programmer still have to write codes to digest the http response message.

  2. It allows only one client namespace which may become inadequate when you may have large amount of POD classes, some of which may shared the same name but in different namespaces in the server side.

  3. Test cases for correctness of WebApiClientGen

Clone this wiki locally