In this article, I am going to discuss Routing Variations in WEB API with some examples. Please read our previous article before proceeding to this article where we discussed the basics of Routing in WEB API.
Understanding HTTP Verbs in Web API.
In the last article, we discussed using the default naming convention provided by Web API Framework. Instead of using the default naming convention for the HTTP methods, you can also explicitly specify the HTTP method for action by decorating the action method with the HttpGet, HttpPut, HttpPost, or HttpDelete attribute.
Let us understand with an example.
Please consider the following controller.
In the above example, the FindAllStudents and FindStudentById actions are mapped to the GET request, while the RemoveStudent action is mapped to DELETE Request and the AddStudent action is mapped to POST Request. If you want to allow multiple HTTP verbs a single action method, or if you to allow HTTP methods other than the GET, PUT, POST, and DELETE, then you need to use the AcceptVerbs attribute, which takes a list of HTTP methods as shown in the below image
In the above example, the FindStudentById action method is mapped to both GET and HEAD HTTP Request.
Routing Variation in Web API by Action Name
With the default routing template, the Web API Framework uses the HTTP method to select the action. However, if you want you can also create your own route where the action name is included as part of the URI as shown in the below image.
In the above route template, the {action} parameter names the action method on the controller. With this style of routing, you need to use the attributes to specify the allowed HTTP methods.
Let us understand this with an example. Please consider the following controller.
In the above example, a GET request for “api/Student/FindAllStudents” would map to the FindAllStudents action method.
In ASP.NET Web API by using the ActionName attribute you can also override the action method name. In the below Student Controller class, we have two actions which map to “api/Student/Image“. One action method supports the GET request while the other one supports the POST HTTP request.
Understanding the NonAction Attribute in ASP.NET Web API:
If you want to prevent an action method from getting invoked as a response to an HTTP request, then you need to decorate that action with the NonAction attribute. This tells the Web API Framework that the method is not an action, even if it would match the routing rules.
As of now, we have discussed a high-level overview of ASP.NET Web API Routing. In the next article, I am going to discuss how the WEB API Framework matches a URI to a route, selects a controller, and then selects the action to invoke. Here, in this article, I try to explain Routing Variations in WEB API step by step with some examples. I hope this Routing Variation in WEB API article will help you with your need.
Summary:
I Hope this post will be helpful to understand Routing Variations in WEB API
Please share this post with your friends and colleagues.
For any queries please post a comment below.
Happy Coding 😉
Understanding HTTP Verbs in Web API.
In the last article, we discussed using the default naming convention provided by Web API Framework. Instead of using the default naming convention for the HTTP methods, you can also explicitly specify the HTTP method for action by decorating the action method with the HttpGet, HttpPut, HttpPost, or HttpDelete attribute.
Let us understand with an example.
Please consider the following controller.
In the above example, the FindAllStudents and FindStudentById actions are mapped to the GET request, while the RemoveStudent action is mapped to DELETE Request and the AddStudent action is mapped to POST Request. If you want to allow multiple HTTP verbs a single action method, or if you to allow HTTP methods other than the GET, PUT, POST, and DELETE, then you need to use the AcceptVerbs attribute, which takes a list of HTTP methods as shown in the below image
In the above example, the FindStudentById action method is mapped to both GET and HEAD HTTP Request.
Routing Variation in Web API by Action Name
With the default routing template, the Web API Framework uses the HTTP method to select the action. However, if you want you can also create your own route where the action name is included as part of the URI as shown in the below image.
In the above route template, the {action} parameter names the action method on the controller. With this style of routing, you need to use the attributes to specify the allowed HTTP methods.
Let us understand this with an example. Please consider the following controller.
In the above example, a GET request for “api/Student/FindAllStudents” would map to the FindAllStudents action method.
In ASP.NET Web API by using the ActionName attribute you can also override the action method name. In the below Student Controller class, we have two actions which map to “api/Student/Image“. One action method supports the GET request while the other one supports the POST HTTP request.
Understanding the NonAction Attribute in ASP.NET Web API:
If you want to prevent an action method from getting invoked as a response to an HTTP request, then you need to decorate that action with the NonAction attribute. This tells the Web API Framework that the method is not an action, even if it would match the routing rules.
As of now, we have discussed a high-level overview of ASP.NET Web API Routing. In the next article, I am going to discuss how the WEB API Framework matches a URI to a route, selects a controller, and then selects the action to invoke. Here, in this article, I try to explain Routing Variations in WEB API step by step with some examples. I hope this Routing Variation in WEB API article will help you with your need.
Summary:
I Hope this post will be helpful to understand Routing Variations in WEB API
Please share this post with your friends and colleagues.
For any queries please post a comment below.
Happy Coding 😉
0 comments:
Post a Comment
If you like this website, please share with your friends on Facebook, Twitter, LinkedIn.