Introduction to REST and .net Web API

If you are building apps or websites today, the chances are you’ll have heard of REST and .net Web API, but you may not be sure what these things are, whether you should use them or how to get started. If this sounds familiar, then this article for you.

API; what and why?

Let’s start right at the start and figure out what an API is and why you should consider using one.

The term API stands for ‘Application Programming Interface’. In the world of web development the term ‘API’ is synonymous with online web services which client apps can use to retrieve and update data. These online services have had several names/formats over the years such as SOAP, however the current popular choice is to create a REST (or RESTful) API.

We’ll come onto REST and why REST is now preferred later, but first let’s examine why you would even bother with an API.

Let’s consider a modern application which may include several mobile apps on various platforms and usually some kind of web application too. Without an API, a basic architecture may look like this where each client app has its own embedded business logic.

Notice that each client app has its own embedded business logic (probably written in several different languages) which connects directly to the database to get, update and manipulate data. This local business logic means that the client apps can easily become complex and all need to be maintained in sync with each other. When a new feature is required, you’ll have to update each app accordingly. This can be a very expensive process which often leads to feature fragmentation, bugs and can really hold back innovation.

Now let’s consider the same architecture with a central API which hold all the business logic.

Each app uses the same API to get, update and manipulate data. All apps have feature parity and when you need to make a change you just make it in one place in line with the ‘Don’t Repeat Yourself’ (DRY) principle of software development. The apps themselves then become relatively lightweight UI layers.

Happy Days

What is REST?

REST stands for ‘Representational State Transfer’ and it is an architectural pattern for creating an API that uses HTTP as its underlying communication method. REST was originally conceived by Roy Fielding in his 2000 dissertation paper entitled ‘Architectural Styles and the Design of Network-based Software Architectures’, chapter 5 cover REST specifically:

Almost every device that is connected to the internet already uses HTTP; it is the base protocol that the internet is built on which is why it makes such a great platform for an API.

HTTP is a request and response system; a calling client sends a request to an endpoint and the endpoint responds. The client and endpoint can be anything but a typical example is a browser accessing a web server or an app accessing and API.

There are several key implementation details with HTTP that you should be aware of:

  • Resources – REST uses addressable resources to define the structure of the API. These are the URLs you use to get to pages on the web, for example ‘’ is a resource
  • Request Verbs – These describe what you want to do with the resource. A browser typically issues a GET verb to instruct the endpoint it wants to get data, however there are many other verbs available including things like POST, PUT and DELETE. See the full list at
  • Request Headers – These are additional instructions that are sent with the request. These might define what type of response is required or authorisation details. See the full list at
  • Request Body - Data that is sent with the request. For example a POST (creation of a new item) will required some data which is typically sent as the request body in the format of JSON or XML.
  • Response Body – This is the main body of the response. If the request was to a web server, this might be a full HTML page, if it was to an API, this might be a JSON or XML document.
  • Response Status codes – These codes are issues with the response and give the client details on the status of the request. See the full list at

In the context of a REST API, resources typically represent your data entities (i.e. ‘Product’, ‘Person’, ‘Order’ etc). The verb that is sent with the request informs the API what to do with the resource, for example a GET request gets data about an entity, POST requests create a new entity.

There is a convention in place that GET requests to an entity url such as /Products returns a list of products, possibly matching some criteria that was sent with the request. However, to retrieve a specific product, you would use the product’s ID as part of the resource, for example /Products/81 would return product with the ID of 81. It is also possible to use query string parameters with an API, for example you may have something like /Products?Colour=red which returns all red products.

These are some typical requests you might expect to see in an ecommerce API:

Resource Verb Expected Outcome Response Code
/Products  GET A list of all products in the system 200/OK
/Products?Colour=red  GET A list of all products in the system where the colour is red 200/OK
/Products  POST Creation of a new product 201/Created
/Products/81  GET Product with ID of 81 200/OK
/Products/881(a product ID which does not exist)  GET Some error message 404/Not
/Products/81  PUT An update to the product with an ID of 81 204/No
/Products/81  DELETE Deletion of the product with an ID of 81 204/No
/Customers  GET A list of all customers 200/OK

What is .net Web API?

.Net’s Web API is an easy way to implement a RESTful web service using all of the goodness that the .net framework provides. Once you understand the basic principles of REST, then a .net Web API will be very easy to implement.

Web API is built on .net’s modular, pluggable pipeline model. This means that when a server hosting a web API receives a request, it passes through .nets request pipeline first. This enables you to easily add your own modules if you find that the default capabilities are not enough for your needs. With the recent announcements on vNext this also means you can potentially host your Web API outside of Windows Server which opens up a whole range of usage cases. See for detail.

Web API uses the Controller and Action concepts from MVC so if you already understand .net MVC you are in a good place. If you don’t, then Web API is a great way to learn MVC.

Resources are mapped directly to controllers; you would typically have a different controller for each of your main data entities (Product, Person, Order etc). Web API uses the .net routing engine to map URLs to controllers. Typically, APIs are held within a ‘/api/’ route which helps to distinguish API controllers from other non-API in the same website.

Actions are used to map to specific HTTP verbs, for example you would typically have a GET action which returns all of the entities. This action would respond to /api/Products (where ‘products’ is your controller) and would look something like this:

 public IEnumerable<string> Get()
return new string[] { "value1", "value2" };

You may also have a GET action which accepts a specific ID and returns a specific entity. It would respond to /api/Products/81 and would look something like this:

 public string Get(int id)
return "value";

There are many great hidden benefits to using Web API which you may not realise but actually save you a lot of work.

Web API is part of ‘One’

Web API is part of the ‘One’ family which means that it natively supports all of the great shared features you may currently use with MVC or web forms, this includes (these are just a few examples):

  • Entity Framework
  • Authorisation and identity
  • Scaffolding
  • Routing

Serialization and Model Binding

Web API is setup by default to provide responses in either XML or JSON (JSON is default). However, as a developer you do not need to do any conversion or parsing – you simply return a strongly typed object and Web API will convert it to XML or JSON and return it to the calling client, this is a process called Content Negotiation. This is an example of a GET action which returns a strongly typed Product object.

 public Product GetProduct(int id)
var product = _products.FirstOrDefault(p => p.ID == id);
if (product == null)
throw new HttpResponseException(HttpStatusCode.NotFound);
return Request.CreateResponse(HttpStatusCode.OK, product);

This also works for incoming requests using a feature called Model Validation. With Model Validation, Web API is able to validate and parse incoming response body data to a strongly typed object for you to work with in your code. This is an example of model binding:

 public HttpResponseMessage Post(Product product)
if (ModelState.IsValid)
// Do something with the product (not shown).

return new HttpResponseMessage(HttpStatusCode.OK);
return Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState);

Dynamic API Help Pages

If you choose Web API as your project type, when you first create your project, you will get automated documentation with your API. This is a regular MVC project that sits alongside your API. The help pages project looks at your API code, models, attributes etc and constructs documentation automatically, which includes examples, model definitions and more.

This documentation makes for a great resource to help developers of calling client understand the structure of your API. Help pages are contained within a route called ‘/help/’.

In Summary

To summarise, use of an API will make the architecture of your application much cleaner, making it easier to add features and fix bugs as your project progresses.

REST is an architectural pattern which is based on HTTP and uses HTTP requests, responses, verbs and status codes to communicate. The fact that REST services use HTTP means they can be consumed by almost any ‘online’ device or application (including IoT devices such as toasters, cars, pedometers etc) – no proprietary knowledge of the API is required.

Web API in .net is the way you write REST APIs services in .net. Web API gives you all the benefits of the .net framework and deals with a lot of the complexities of content negotiation, model binding etc that you’d have to deal with yourself without Web API.

To get started with Web API, I’d recommend you initially take a look at my 6 minute video which talks through the process of creating a very simple web API:

Then you should take a look on the official sub site which has plenty of tutorials, examples and videos:

Comments (40)

  1. Osman says:

    This is an amazing article, I appreciate it.

  2. Osman says:

    This is an amazing article, I appreciate it.

  3. Ash says:

    So far this the Best article I found which clearly explains diff between REST and Web APIs. Thank you so much!!!

  4. Ian says:

    As a BSA having to learn and document web service requirements, this is really appreciated. It’s so clearly written and the links to other resources are all good.

  5. Zaheer Mirza says:

    Awesome and Useful!

  6. Arunkumar says:

    Good article, very helpful.

  7. Nazli says:

    This was so helpful, So simple and at the same time covers everything we should know about Web API.
    I appreciate it.

  8. ritesh says:

    very useful, thanks!

  9. Arun says:

    Very useful content for the Web API 🙂

  10. Raed says:

    Helpful article.
    Is there any official course from microsoft for API and REST ?

  11. Sumesh says:

    Nice article. Gives a clear overview about Rest and webapi to dummies.
    Couple of semantic corrections :
    1. PUT verb is used to create resource and POST to update. The article specifies vice versa.
    2. Under the Model validation, it is the request that is being validated and not response.

    Though it is easy to infer them correctly, it would be good to correct them

  12. ganesh kumar says:

    Excellent article with crisp explanation on Web API’s and REST principles

  13. Ross says:

    Good article!

  14. John says:

    Many thanks for the easy explanations

  15. Cristobal says:

    Very useful article! Thanks

  16. Sovi says:

    Very well written article. I like how you have discussed the concepts of RESTFul web and API concisely in such a short article.

  17. Dessa says:

    This sort of overview is exactly what I’ve been looking for. Thank you SO much,.

  18. divine dela says:

    This is the best introductory article i have found on REST and .net Web API. Your diagrams communicated a lot.

  19. Prabhakar kumar priyadarshi says:

    Finally, I am able to understand Api, restfull .greate articles kudos for you

  20. Syed Rahim says:

    excellent articles

  21. binu says:

    Very good article. Simple to understand. Thanks.

  22. Murtaza Jaffari says:

    Great article !!

  23. Edalat says:

    This is an amazing article, Describes web api architecture very good.thanks

  24. Mahendra says:

    This article gives you the clear picture of what is REST and Web API. 🙂

  25. Aprian says:

    Thank you, the world needs a man like you.

  26. Nikhil says:

    Nice…Very Useful

  27. nair says:

    No doubt! Precise and Prefect!

  28. TRiz says:

    Concise and Informative.

  29. Hanieh says:

    thanks an ocean , you wrote so well….

  30. Tolster says:

    Thank you so much

  31. Vaibhav says:

    This article explains Web API in very easy language. Really appreciate your efforts in making so easy for techies.

  32. Sanya says:

    Very useful information.Thank You!

  33. Helpful article, but it’s not entirely accurate. The second diagram implies that the need business logic disappears in client applications altogether when you use a Web API. In reality, a fair amount of business logic still needs to exist in client applications, but I guess one could limit what is considered “business logic”. Coding business logic into client apps (like mobile devices) makes the experience much more responsive and is a requirement for offline-capable apps. There are other reasons for doing so such as reduced round-trips to the server and scalability (using client resources). That said, never trust the client with respect to data submission; ensure any business rules or validations are repeated on the server-side. This violation of the DRY principle can be somewhat mitigated if you happen to be using shared libraries (i.e. between API and MVC Web) or shared PCLs (i.e. between API and Xamarin app).

  34. Iftikhar says:

    What if the business logic is different between clients.
    Couple of scenarios:
    1. A healthcare application is only allowed to see patients data in the office where user is logged into.
    2. However, a reporting application should be able to patient data across health offices.

    Should API (business logic) be generic to allow client application to tell whether to load data across offices or only current office? or the BL Layer hidden behind rest api should validate client and see which api calls/combination is allowed? The second option may be needed if you don’t trust client applications.

  35. François says:

    Good article and video. A truly nice way to open the door.

  36. Catherine says:

    This is the best article i came across, well written and helped me understand the concept better . Thank you .

  37. Alex says:

    Very well explained for anyone. Just go and look at the crap on something simple like WEB API and REST on the net. Of course it can get complex, but the basics can be easily understood with a simple article like this, and developers STRUGGLE and go into an entire new multiverse trying to explain something this simple. Good work. I’d recommend it to anyone who needs to teach all this. Fantastic.

  38. Ananch says:

    Good one to read. Thanks.

  39. Preetham says:

    This article was really helpful. Thank you.

Skip to main content