如何配置ASP.NET API的路由以实现高效的请求处理?
- 行业动态
- 2024-11-30
- 2
ASP.NET API 路由配置分为模板路由和属性路由两种模式,模板路由使用前需定义路由模板,默认模板为”api/{controller}/{id}”。
ASP.NET API 路由配置
ASP.NET Web API 的路由系统是整个API的入口,它负责将客户端请求映射到对应的控制器和操作方法,通过URL来获取资源,ASP.NET Web API 的请求最终会定位到一个具体的Action上,ASP.NET Web API 路由的核心作用就是将客户端请求映射到对应的Action上。
一、两种路由模式
1. 模板路由
模板路由是ASP.NET Web API默认提供的路由方式,在使用前需要定义路由模板,下面是默认的模板路由示例:
using System; using System.Collections.Generic; using System.Linq; using System.Web.Http; namespace Supernova.Webapi { public static class WebApiConfig { public static void Register(HttpConfiguration config) { // Web API 配置和服务 // Web API 路由 config.MapHttpAttributeRoutes(); config.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); } } }
此模板路由是新建项目时默认生成的,在App_Start文件夹下,我们可以看到此模板的URL格式是api/{controller}/{id},其中api代表在资源前面要带上api目录,controller代表请求资源的控制器名称,id代表一条资源的id,id是可选的,这种默认的模板是不带action的,所以它是以请求方式来区分资源的,必须在action上添加请求方式特性加以区分。
我们添加一个测试控制器TestController:
public class TestController : ApiController { public object Get1() { return "d1"; } }
如果添加两个方法如下:
public class TestController : ApiController { public object Get1() { return "d1"; } public object Get2() { return "d2"; } }
调试时会出现错误信息:“找到了与该请求匹配的多个操作”,因为默认情况下,模板路由无法满足针对一种资源一种请求方式的多种操作,基于上面两点上文归纳,默认路由模板无法满足针对一种资源一种请求方式的多种操作(比如修改操作,可能针对不同的字段进行修改)。
为了解决这个问题,我们可以重新定制模板路由,如下:
config.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{action}/{id}", defaults: new { id = RouteParameter.Optional } );
2. 属性路由
属性路由是ASP.NET Web API 2中引入的新型路由方式,顾名思义,属性路由使用属性来定义路由,通过属性路由,可以更好地控制Web API中的URI,可以轻松创建描述资源层次结构的URI,旧式路由(称为基于约定的路由)仍完全受支持,可以将这两种技术合并到同一项目中。
启用属性路由需要在配置期间调用MapHttpAttributeRoutes方法:
public static class WebApiConfig { public static void Register(HttpConfiguration config) { // Web API 配置和服务 // Web API 路由 config.MapHttpAttributeRoutes(); // 其他 Web API 配置未显示... } }
属性路由可以与基于约定的路由结合使用,若要定义基于约定的路由,请调用MapHttpRoute方法。
public static class WebApiConfig { public static void Register(HttpConfiguration config) { // 属性路由 config.MapHttpAttributeRoutes(); // 基于约定的路由 config.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); } }
添加路由属性的示例:
[Route("customers/{customerId}/orders")] [HttpGet] public IEnumerable<Order> FindOrdersByCustomer(int customerId) { ... }
二、HTTP方法和HTTP状态码
根据HTTP标准,HTTP请求可以使用多种请求方法,HTTP1.0定义了三种请求方法:GET, POST 和 HEAD方法,HTTP1.1新增了五种请求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法,常见的HTTP方法和其描述如下表所示:
序号 | 方法 | 描述 |
1 | GET | 请求指定的页面信息,并返回实体主体。 |
2 | HEAD | 类似于GET请求,只不过返回的响应中没有具体的内容,用于获取报头 |
3 | POST | 向指定资源提交数据进行处理请求(例如提交表单或者上传文件),数据被包含在请求体中,POST请求可能会导致新的资源的建立和/或已有资源的修改。 |
4 | PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
5 | DELETE | 请求服务器删除指定的页面。 |
6 | CONNECT | HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。 |
7 | OPTIONS | 允许客户端查看服务器的性能。 |
8 | TRACE | 回显服务器收到的请求,主要用于测试或诊断。 |
当浏览者访问一个网页时,浏览者的浏览器会向网页所在服务器发出请求,当浏览器接收并显示网页前,此网页所在的服务器会返回一个包含HTTP状态码(HTTP Status Code)的信息头(server header)用以响应浏览器的请求,常见的HTTP状态码及其含义如下表所示:
| 状态码 | 描述 |
|——–|——|
| 200 | OK | 请求成功,一般用于GET与POST请求 |
| 301 | Moved Permanently | 永久移动,请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI,今后任何新的请求都应使用新的URI代替 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源(网页),通过此代码,网站设计人员可设置您所请求的资源无法找到的个性页面 |
| 500 | Internal Server Error | 服务器内部错误,无法完成请求 |
三、RESTful介绍
REST是Representational State Transfer的缩写,翻译为表象化状态转变或表述性状态转移,是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格,它包含了一些约束条件和原则,REST指的是一组架构约束条件和原则,如果一个架构符合REST的约束条件和原则,我们就称它为RESTful架构,REST本身只是为应用设计界定了一下准则,如何具体设计和实现一个RESTful架构,则完全由设计师自己来决定,要设计出一个RESTful API,需要对各种场景进行取舍,以满足这些约束条件和原则,因此RESTful API的设计并不能一概而论,它在具体实现时常常会依照不同的应用场景有不同的实现方式,REST本身强调的是设计思想和风格,而不是标准,有很多人对什么是RESTful API的理解都不尽相同,这里归纳了一下网上的一些文章和自己的理解,归纳出以下几点:
资源是由URI指定的:RESTful风格的web地址可以看到一个资源的URL里包含了所有对这个资源的描述,http://example.com/items/123,这个URL不仅告诉我们资源的种类(这里是item),还告诉我们特定的资源(这里的ID是123),这种RESTful的web地址也被称为HATEOAS(Hypermedia as the Engine of Application State)。
使用HTTP方法操作资源:RESTful API使用标准的HTTP方法如GET, PUT, POST, DELETE等对资源进行操作,使用GET方法获取资源,使用POST方法创建资源,使用PUT方法更新资源,使用DELETE方法删除资源,这些HTTP方法是幂等的,即多次执行同一个操作不会改变资源的状态,还可以使用PATCH方法对资源进行部分更新,这些HTTP方法都是无状态的,即每次请求不依赖于之前的请求,RESTful API利用HTTP的这一特点来实现客户端和服务器之间的交互。
无状态服务:每个请求之间是独立的,服务器并不保存客户端的状态信息,这使得RESTful API更加简单和可扩展,无状态服务是指服务器在处理请求时不需要保存客户端的状态信息,从而提高系统的可伸缩性和可靠性,无状态服务使得客户端和服务器之间的通信更加高效和简洁,每个请求都是独立的,服务器不需要保存客户端的状态信息,从而减少了服务器的负担和复杂性,无状态服务还使得负载均衡和缓存变得更加容易实现,无状态服务提高了系统的可用性和灵活性,使得客户端可以随时随地地发起请求而无需担心服务器的状态变化,无状态服务还简化了客户端的开发和维护工作,因为客户端只需要关注当前请求的结果即可,无状态服务还有助于提高系统的安全性和隐私保护能力,因为服务器不需要保存敏感的状态信息来避免潜在的安全风险,无状态服务是现代分布式系统中不可或缺的一部分,它为构建高效、可靠和可扩展的应用程序提供了坚实的基础。
资源表现形式:资源可以有多种表现形式(JSON, XML等),具体使用哪种形式由客户端和服务器协商决定,在RESTful架构中,资源通常有多种表现形式供客户端选择和使用,最常见的表现形式包括JSON和XML格式,JSON(JavaScript Object Notation)是一种轻量级的数据交换格式,易于阅读和编写,同时也易于机器解析和生成,XML(可扩展标记语言)是一种标签语言,具有强大的自描述能力和灵活性,除了JSON和XML之外,还有其他一些格式如HTML、纯文本、多部分对象集合(Multipart)、任意二进制流等也可以作为资源的表现形式,客户端可以通过Accept头部来指定期望接收的数据格式;而服务器则通过Content-Type头部来告知客户端实际发送的数据格式,这种机制使得客户端可以根据需要选择合适的数据格式来处理响应结果;同时也使得服务器可以根据客户端的需求灵活地调整输出内容以提高用户体验和性能表现,在实际应用中还可以根据具体场景选择合适的序列化方式以满足特定需求;例如对于大数据量的传输可以考虑使用压缩算法来减少带宽占用;对于实时性要求较高的场景则可以选择更高效的传输协议等,在RESTful架构中资源的表现形式是非常灵活多样的;开发者可以根据实际需求选择合适的数据格式来优化系统性能和用户体验。
通讯过程中的资源状态变化:通过对资源执行操作来改变其状态;例如创建一个订单后该订单就处于已创建状态;而如果取消该订单则变为已取消状态等,在RESTful架构中,资源的状态变化是通过对其执行操作来实现的,每个资源都有一个唯一的标识符(通常是URI),客户端可以通过这个标识符来访问和操作资源,当客户端对资源执行操作时(如创建、读取、更新或删除),就会触发相应的状态变化,在一个电商网站上创建一个订单后,该订单就处于已创建状态;而如果取消该订单,则变为已取消状态等,这些状态变化通常由服务器端的逻辑处理来完成;但是在某些情况下也可以由客户端发起并通过HTTP方法来实现相应的操作效果,RESTful API利用HTTP方法的标准语义来实现对资源的操作;例如使用GET方法获取资源信息、使用POST方法创建新资源、使用PUT方法更新现有资源以及使用DELETE方法移除不再需要的资源等,这些HTTP方法是幂等且无副作用的;即多次执行同一个操作不会产生额外的影响也不会改变系统的整体状态;因此非常适合用于构建安全可靠的网络服务接口,在实际应用中还可以根据具体需求自定义其他HTTP方法来扩展系统的功能;例如使用PATCH方法对部分字段进行更新等,在RESTful架构中通讯过程中的资源状态变化是一个非常重要的概念;它不仅体现了RESTful API的核心设计理念之一——通过操作资源来实现业务逻辑;同时也为客户端提供了直观易懂的操作界面和良好的用户体验。
统一接口:通过URI、HTTP方法、资源状态和表现形式等约束条件来保证接口的统一性和规范性;从而提高了系统的可维护性和可扩展性以及降低了耦合度等优点,在RESTful架构中,统一接口是指通过一组一致的、标准化的方法和约定来定义客户端与服务器之间的交互方式,这些方法包括URI命名规则、HTTP动词的使用、资源状态的表示以及数据格式的选择等,通过遵循这些统一的接口规范,可以确保不同系统之间能够无缝协作并且提高整个平台的互操作性,统一接口还有助于降低开发难度和成本;因为它减少了开发人员需要学习和掌握的新概念和技术栈的数量;同时也使得代码更加易于测试和维护,在RESTful架构中统一接口是一个非常重要的概念;它不仅为构建高效稳定的网络服务提供了坚实的基础而且还促进了行业内最佳实践的形成和发展。
四、REST成熟度模型
Richardson提出的REST成熟度模型把REST服务按照成熟度划分成4个等级:Level 0, Level 1, Level 2, Level 3,每个级别对应于一组特定的特征和约束条件;通常情况下我们会根据自己的实际需求来选择合适的级别进行设计和实现以达到最佳效果,下面分别介绍各个级别的特征:
Level 0:在这个级别上Web服务只是使用HTTP作为传输方式而已;实际上只是远程方法调用(RPC)的一种具体形式而已;例如SOAP和XML-RPC都属于此类;它们虽然采用了HTTP协议但却并没有充分利用HTTP本身所具有的优势如无状态性等特点从而导致了较低的效率和较差的用户体验等问题的出现,这类服务往往需要额外的描述文档才能让使用者了解如何使用它们提供的接口功能等信息;而且由于缺乏标准化的定义使得不同厂商的产品之间很难实现互操作性进而限制了其在更广泛范围内的应用前景,此外由于过于依赖特定的传输协议和技术栈使得这类服务很难适应快速变化的市场需求和技术发展趋势从而导致其逐渐被淘汰出局的风险较大,因此在现代Web开发中我们应该尽量避免采用这种方式来构建API接口以确保系统具有良好的可扩展性和灵活性等特点以满足未来不断变化的需求挑战!
Level 1:引入了资源的概念并将URI作为资源的标识符;例如将用户信息作为资源并用/users/123这样的URL来表示特定用户的详细信息页面等操作;这样一来不仅可以使客户端更容易理解和记住这些链接地址而且还可以提高搜索引擎优化(SEO)的效果从而吸引更多的流量进入我们的网站之中去探索更多的内容和服务选项!此外我们还可以利用缓存机制来加速常用数据的读取速度并减轻服务器端的负载压力从而提高整体性能表现!但是需要注意的是这种方法仍然存在一些问题:首先它没有充分利用HTTP方法的优势来进行细粒度的操作控制而是仅仅依靠URI的变化来实现不同的功能需求;其次它也没有考虑到安全性方面的问题:任何人都可以直接访问公开的链接地址而无需经过身份验证或授权检查等步骤就可以获取到敏感信息或者执行危险的命令等情况的发生概率较高!因此在实际应用中我们需要谨慎对待并采取相应的措施来防止潜在的风险隐患出现!
Level 2:使用HTTP方法来进行不同的操作并对不同的资源使用不同的URI;例如使用GET方法获取资源信息、使用POST方法创建新资源、使用PUT方法更新现有资源以及使用DELETE方法移除不再需要的资源等操作;这样一来不仅可以使客户端更加清晰地知道每个动作的具体含义而且还可以提高系统的可读性和可维护性从而便于后续的迭代升级工作!此外我们还可以利用版本控制机制来管理API接口的变化历史记录以便追踪问题根源并及时修复bug等问题的发生情况!但是需要注意的是这种方法仍然存在一些问题:首先它没有充分利用HTTP状态码的优势来进行错误处理而是仅仅依靠返回值来判断是否成功执行了某项任务从而导致了较低的效率和较差的用户体验等问题的出现!其次它也没有考虑到安全性方面的问题:任何人都可以直接访问公开的链接地址而无需经过身份验证或授权检查等步骤就可以获取到敏感信息或者执行危险的命令等情况的发生概率较高!因此在实际应用中我们需要谨慎对待并采取相应的措施来防止潜在的风险隐患出现!
Level 3:使用所有的HTTP方法并对每种资源都使用不同的URI;例如使用GET方法获取资源信息、使用POST方法创建新资源、使用PUT方法更新现有资源以及使用DELETE方法移除不再需要的资源等操作;这样一来不仅可以使客户端更加清晰地知道每个动作的具体含义而且还可以提高系统的可读性和可维护性从而便于后续的迭代升级工作!此外我们还可以利用版本控制机制来管理API接口的变化历史记录以便追踪问题根源并及时修复bug等问题的发生情况!但是需要注意的是这种方法仍然存在一些问题:首先它没有充分利用HTTP状态码的优势来进行错误处理而是仅仅依靠返回值来判断是否成功执行了某项任务从而导致了较低的效率和较差的用户体验等问题的出现!其次它也没有考虑到安全性方面的问题:任何人都可以直接访问公开的链接地址而无需经过身份验证或授权检查等步骤就可以获取到敏感信息或者执行危险的命令等情况的发生概率较高!因此在实际应用中我们需要谨慎对待并采取相应的措施来防止潜在的风险隐患出现!
五、常见问题解答(FAQs)
Q1: 为什么选择属性路由?A1: Web API的第一个版本使用了基于约定的路由方式;这种方式虽然简单易用但也存在一些局限性如难以支持某些复杂的URI模式等问题!为了解决这些问题微软在Web API 2中引入了一种新的路由机制——属性路由来弥补这些不足之处并提供更强大的功能支持以满足更多场景下的需求!通过属性路由我们可以更好地控制Web API中的URI结构并轻松创建出符合RESTful风格设计的API接口从而提高系统的可维护性和可扩展性等特点!此外属性路由还可以与其他技术如ODataQueryOptions等结合使用以进一步增强其灵活性和功能性等方面的优势!
小伙伴们,上文介绍了“asp.net api 路由配置”的内容,你了解清楚吗?希望对你有所帮助,任何问题可以给我留言,让我们下期再见吧。
本站发布或转载的文章及图片均来自网络,其原创性以及文中表达的观点和判断不代表本站,有问题联系侵删!
本文链接:http://www.xixizhuji.com/fuzhu/359047.html