Web-based APIs

We develop either a Web App (Frontend) or a Web API (Backend).

The Model View Control (MVC) architecture can be used for the Web Apps because the Web APIs don’t have View/UI. But still the same architecture can be used for backends/Web APIs with model & controller but without View.

All the APIs have somethings in common:

  • Stratus code
  • Actions
  • Input and Output Content Formatter

Status Code

Level 200
Success
Level 300
Redirection
Level 400
Client Error
Level 500
Server Error
200 – Ok
201 – Create
204 – No Content (for the requests which shouldn’t return anything like delete)
– tell the search engine that a page has permanatly moved.
– Most APIs don’t have need for this.
400 – Bad Request
401 – Unauthorized
403 – Forbidden
404 – Not found
409 – Conflict
500 – Internal Server Error

Input and Output Content Formatter

Media type is passed via the Accept header of the request. The media type can be the followings:

Output Formatter
(accept header)
Input Formatter
(content-type header)
application/json
application/xml

Attention: Using Azure App Service for deploying your code?

If an API will be deployed with .Net Core and via Azure App Service. We must pay attention to the version of the .Net Core in IDE and the supported versions of the Runtime Stack in Azure App Service. The following figure demonstrates the web app creation blade via Azure App Service.

Azure App Service blade

The following image demonstrates the current supported runtime stacks.

The Runtime Stack version, which are supported at the time of writting this document on Azure App Service

Or we can use the containerized application to by pass the runtime version limitations.

%d bloggers like this: