ASP.NET Web API

HTTP Status Codes are the 3 digit integers which contain in server response. There is a meaning for each number. Response Header of each API response contains the HTTP Status Code. The first digit of the Status-Code defines the class of response. HTTP Status Codes are grouped into five categories based upon the first number. 

Following are the set of status codes with its meaning:

• 1xx: Informational-It means the request has been received and the process is continuing. 
• 2xx: Success-It means the action was successfully received, understood, and accepted. 
• 3xx: Redirection-It means further action must be taken in order to complete the request. 
• 4xx: Client Error-It means the request contains incorrect syntax or cannot be fulfilled 
• 5xx: Server Error-It means the server failed to fulfill an apparently valid request. 

Some of the commonly seen HTTP Status Codes are: 200 (Request is Ok), 201 (Created), 202 (Accepted), 204 (No Content), 301 (Moved Permanently), 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found), 500 (Internal Server Error), 502 (Bad Gateway), 503 (Service Unavailable) etc. 

HTTP header fields are components of the header section of request or response messages in the Hypertext Transfer Protocol. It defines the operating parameters of an HTTP transaction. There are more contents in an HTTP header field.

For example, HTTP request to fetch aspnetwebapi.htm page from the web server running on developmenthelp.net.

A must-know for anyone heading into Web API interview, this is frequently asked in Web API interview questions.  

Media Type is a file identification mechanism on the MIME encoding system, formerly “MIME type”. The Internet media type has become the de facto standard for identifying content on the Internet.

For example, consider an instance of receiving an email from a server with an attachment, the server embeds the media type of the attachment in the message header. So, the browser can launch the appropriate helper application or plug-in.

It's no surprise that this one pops up often in Web API scenario based interview questions.  

It is difficult to say which one is better between Web API and WCF Rest service. Both the technologies have their own significant in the context of development, hosting and consuming the service.Although both WCF REST and ASP.NET Web API follow the REST architecture, these have the following differences:  

WCF Rest 

• Microsoft has introduced “WebHttpBinding” that needs to be enabled for creating WCF RESTful Services. 
• HTTP Methods are mapped to attributes. So, for each method there must be attributes like – “WebGet” for GET and “WebInvoke” for POST verbs. 

Web API 

• Unlike WCF Rest we can use the full features of HTTP in Web API. 
• Web API can be hosted in IIS or in applications. 

It completely depends upon the requirement. Choose ASP.NET Web API if you want HTTP based services only, as Web API is a lightweight architecture and is good for the devices which have limited bandwidth. We can also create the REST services with WCF, but that requires a lot of configuration. In case you want a service that should support multiple transport protocols like HTTP, UDP, TCP, etc. then WCF will be the better option.

This is a regular feature in Web API interview questions, be ready to tackle it.  

WCF 

• It is a framework built for building or developing service-oriented applications. 
• It is designed to exchange standard SOAP-based messages 
• WCF can be consumed by clients which can understand XML. 
• WCF supports a variety of transport protocols like – HTTP, TCP, Named Pipes or MSMQ etc. 
• iWCF ships out with the .NET Framework.  
• WCF service is good for Message Queue, duplex communication, one-way messaging. 

Web API 

• Web API is an open source platform. 
• It is a framework which helps us to build/develop HTTP services using HTTP verbs 
• It supports most of the MVC features which keep Web API over WCF. 
• The purpose of Web API framework is to generate HTTP services that reach more clients by generating data in raw format, for example, plain XML or JSON string. So, ASP.NET Web API creates simple HTTP services that render raw data. 
• This returns XML or JSON to client. 
• All requests are mapped to actions using HTTP verbs. 
• We cannot return a view from WebAPI 
• In the ASP.NET Web API request is mapped to Action based on the Action Verbs. 

MVC 

• ASP.NET MVC is used to create a web application which returns both data as well as View (HTML) whereas Web API is used to create HTTP based Services which only returns data and not view.  
• ASP.NET MVC facilitates in easyrendering of HTML. 
• MVC is used to create a web app, in which we can build web pages. 
• JSONit will return JSONResult from action method. 
• All requests are mapped to the respective action methods. 
• We can return a view from MVC 
• In an ASP.NET MVC application, requests are mapped to Action Methods. 

REST stands for Representational State Transfer. This term was coined by Roy Fielding in 2000. RESTful is an Architectural style for creating loosely coupled applications over HTTP. In order to make API to be RESTful, it must adhere to the around 6 constraints that are mentioned below: 

• Client and Server Separation: Server and Clients are clearly isolated in the RESTful services. 

This constraint specifies that a Client sends a request to the server and the server sends a response back to the client. This separation of concerns supports the independent development of both client-side and server-side logic. That means client application and server application should be developed separately without any dependency on each other. A client should only know resource URIs and that’s all. Severs and clients may also be replaced and developed independently as long as the interface between them is not altered.  

• Stateless: REST Architecture is based on the HTTP Protocol and the server response can be cached by the clients, but no client context would be stored on the server. 

The stateless constraint specifies that the communication between the client and the server must be stateless between requests. This means that we should not be storing anything on the server related to the client. The request from the client should contain all the necessary information for the server to process that request. This ensures that each request can be treated independently by the server.  

• Uniform Interface: Allows a limited set of operations defined using the HTTP Verbs. For eg: GET, PUT, POST, Delete etc. 

The uniform interface constraint defines an interface between the client and the server. To understand the uniform interface constraint, we need to understand what a resource is and the HTTP verbs – GET, PUT, POST and DELETE. In the context of a REST API, resources typically represent data entities. The product, Employee, Customer, etc. are all resources. The HTTP verbs (GET, PUT, POST, and DELETE) that are sent with each request tell the API what to do with the resource. Each resource is identified by a specific URI (Uniform Resource Identifier).  

• Cacheable: RESTful architecture allows the response to be cached or not. Caching improves performance and scalability. 

Some data provided by the server like the list of products, or list of departments in a company does not change that often. This constraint lets the client know how long this data holds good, so that the client does not have to come back to the server for that data over and over again.  

• Code-On-Demand:is any technology that sends executable software code from a server to a client upon request from the client. The program code lies inactive on a web server until a client requests a web page that contains a link to the code using the client's web browser. Upon this request, the web page and the program are transported to the user's machine using HTTP. When the page is displayed, the code is started in the browser and executes locally, inside the user's computer until it is stopped (e.g., by the user leaving the web page). 
• Layered System:REST allows us to use a layered system architecture where we deploy the APIs in server A, and store data on server B and authenticate requests in server C. For example, a client cannot ordinarily tell whether it is connected directly to the server or to an intermediary along the way.  

This is frequently asked in Web API interview questions for experienced.  

We can unit test the Web API using the Fiddler tool. Below are the settings to be done in Fiddler –Compose Tab -> Enter Request Headers -> Enter the Request Body and execute.