Creating API Help Pages

Install ASP.NET and Web Tools 2012.2 Update. This update integrates help pages into the Web API project template.

Next, create a new ASP.NET MVC 4 project and select the Web API project template. The project template creates an example API controller named ValuesController. The template also creates the API help pages. All of the code files for the help page are placed in the Areas folder of the project.

When you run the application, the home page contains a link to the API help page. From the home page, the relative path is /Help.

This link brings you to an API summary page.

The MVC view for this page is defined in Areas/HelpPage/Views/Help/Index.cshtml. You can edit this page to modify the layout, introduction, title, styles, and so forth.

The main part of the page is a table of APIs, grouped by controller. The table entries are generated dynamically, using the IApiExplorer interface. (I’ll talk more about this interface later.) If you add a new API controller, the table is automatically updated at run time.

The “API” column lists the HTTP method and relative URI. The “Description” column contains documentation for each API. Initially, the documentation is just placeholder text. In the next section, I’ll show you how to add documentation from XML comments.

Each API has a link to a page with more detailed information, including example request and response bodies.

Adding Help Pages to an Existing Project

You can add help pages to an existing Web API project by using NuGet Package Manager. This option is useful you start from a different project template than the “Web API” template.

From the Tools menu, select Library Package Manager, and then select Package Manager Console. In the Package Manager Console window, type one of the following commands:

For a C# application: Install-Package Microsoft.AspNet.WebApi.HelpPage

For a Visual Basic application: Install-Package Microsoft.AspNet.WebApi.HelpPage.VB

There are two packages, one for C# and one for Visual Basic. Make sure to use the one that matches your project.

This command installs the necessary assemblies and adds the MVC views for the help pages (located in the Areas/HelpPage folder). You’ll need to manually add a link to the Help page. The URI is /Help. To create a link in a razor view, add the following:

@Html.ActionLink("API", "Index", "Help", new { area = "" }, null)

Also, make sure to register areas. In the Global.asax file, add the following code to the Application_Start method, if it is not there already:

protected void Application_Start()
 // Add this code, if not present.

// ...

Adding API Documentation

By default, the help pages have placeholder strings for documentation. You can use XML documentation commentsto create the documentation. To enable this feature, open the file Areas/HelpPage/App_Start/HelpPageConfig.cs and uncomment the following line:

config.SetDocumentationProvider(new XmlDocumentationProvider(

Now enable XML documentation. In Solution Explorer, right-click the project and select Properties. Select the Buildpage.

Under Output, check XML documentation file. In the edit box, type “App_Data/XmlDocument.xml”.

Next, open the code for the ValuesController API controller, which is defined in /Controllers/ValuesControler.cs. Add some documentation comments to the controller methods. For example:

/// <summary>
/// Gets some very important data from the server.
/// </summary>
public IEnumerable<string> Get()
 return new string[] { "value1", "value2" };

/// <summary>
/// Looks up some data by ID.
/// </summary>
/// <param name="id">The ID of the data.</param>
public string Get(int id)
 return "value";


Tip: If you position the caret on the line above the method and type three forward slashes, Visual Studio automatically inserts the XML elements. Then you can fill in the blanks.

Now build and run the application again, and navigate to the help pages. The documentation strings should appear in the API table.

The help page reads the strings from the XML file at run time. (When you deploy the application, make sure to deploy the XML file.)

Under the Hood

The help pages are built on top of the ApiExplorer class, which is part of the Web API framework. The ApiExplorerclass provides the raw material for creating a help page. For each API, ApiExplorer contains an ApiDescription that describes the API. For this purpose, an “API” is defined as the combination of HTTP method and relative URI. For example, here are some distinct APIs:

  • GET /api/Products
  • GET /api/Products/{id}
  • POST /api/Products

If a controller action supports multiple HTTP methods, the ApiExplorer treats each method as a distinct API.

To hide an API from the ApiExplorer, add the ApiExplorerSettings attribute to the action and set IgnoreApi to true.

[ApiExplorerSettings(IgnoreApi=true)] public HttpResponseMessage Get(int id) { }

You can also add this attribute to the controller, to exclude the entire controller.

The ApiExplorer class gets documentation strings from the IDocumentationProvider interface. As you saw earlier, the Help Pages library provides an IDocumentationProvider that gets documentation from XML documentation strings. The code is located in /Areas/HelpPage/XmlDocumentationProvider.cs. You can get documentation from another source by writing your own IDocumentationProvider. To wire it up, call the SetDocumentationProviderextension method, defined in HelpPageConfigurationExtensions

ApiExplorer automatically calls into the IDocumentationProvider interface to get documentation strings for each API. It stores them in the Documentation property of the ApiDescription and ApiParameterDescription objects.

Orginal article

Difference between POST and PUT

I was asked a question today about what was the difference between POST and PUT when referring to HTTP.

There seems to be some confusion over what people understand it to be; it is quite simple, just to avoid any confusion here is the RFC itself explains the core difference:

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request — the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.