REST(3), Web API

Web API is a popular tool used for current middle-tier development. Web API is based on the concept of REST. These two articles are summaries of REST and REST-related issues with my understanding.

The second article was my learning notes several years ago, summarizing the REST features, related issues and my understanding. When I tried to rewrite them into an article, I found out that I should review and briefly summarize the basic concept of REST, but that is not just easy work and can be done in several words or sentences. Then I think I'd better write another article for the basic concept of REST, that is REST(1), In Concept.

The third article was a presentation in a REST Web API forum, In that, I used some materials coming from the first two articles, but I discussed them in a different angle.


This will be the contents of this article,

  • A - REST
  • B - REST Based Service vs. RESTful Service
    • Samples
      • RESTful: Web API
      • REST Based: MVC
  • C - Why used to NOT be RESTful?
  • D - Why we Should use REST Web API


B - RESTful Service and REST Based Service




RESTful: Web API, created by VS studio Scaffolder

We can see, in the auto-created code, the VERBs

are exactly match the ACTIONs by RESTful:

REST Based: MVC, created by VS studio Scaffolder

in the auto-created code, the VERBs

are not exactly match the ACTIONs:

  • GET --- Fetch
  • POST --- Create
  • POST --- Update
  • POST --- Delete

C - Why used NOT to be RESTful, even for Web API

Actually, for convenience, we have enough reasons to use REST based approach, instead of, RESTful, even for Web API. For example, we used POST for all Create, Update and Delete.

First Reason:

Second Reason:

Use POST as a universal package that can save time, one piece of code can handle all situations

Especially before .NET 4.5, HttpClient, only WebRequest, and its light version WebClient available:

We can use POST to handle everything:

Third Reason:

Use Stored Procedure to talk to database: always using POST

When I worked for a company, such as prudential financial, that has a very strict security policy that user (app) can only access database by Stored Procedure, no access to tables.

At this point, I used Entity Framework, associated with Stored Procedure:

Then, everything is handled by POST: t [ASP.NET Core, Web API - Entity Framework Call Stored Procedure Implementation]

Fourth Reason:

Sometimes, even we use entity framework associated with Web API, however the business logic is not exactly mapping front end entities to back end database, instead, the functionality is qutie complex, such as starting a remove Azure virtual machine, shutting down the machine, or restarting, the actions are not just CRUD (create, read, update and delete) to database.  At that time, we might choose what the verb we like and applicable:

D - Why we Should use REST Web API

I worked in different companies, it seems most companies do not care if the Web API code is following exactly RESTfule rules. I believe the main reason is if the product is used internally, they usually do not care, especially there were some other reasons, such as legacy code.

On the other hand, if the product is shared by public or by different clients, they usually need to make Web API following RESTful rules.  The reason is simple, they are APIs, contracts between API producers and consumers, so both side have to follow the contracts.

Microsoft .Net Core Web API

Exactly following the RESTful rules, while even .Net framework not:

the verbs and actions are exactly matched to each other by RESTful:

The swagger shows the results:

The output (Microsoft .Net Core) is automatically matching what the RESTful required, even the name convention (we will discuss the RESTful name convention in the next article --- REST(4), Web API Naming Convension)

However, for .Net Framework, even for the latest version, 4.8, it is not fully RESTful automatically:

The output is not following the RESTful name convention:




This article is about understanding the concept of REST and RESTful service in practice.


Similar Articles