血源诅咒老猎人,华宏mba,练字网
本文所需的一些预备知识可以看这里: 和
本文介绍的是使用ASP.NET Core建立Richardson成熟度为2级的伪RESTful web API, 本文介绍的是GET和POST.
使用的项目是(右键另存为, 然后把后缀名改为zip):
首先, 资源应该使用名词, 它是个东西, 不是动作.
例如:
所以资源应该使用的是名词.
如果是非分层结构的资源, 那么它不应该这样命名: api/xxx/xxx/users, 而应该使用 api/users.
如果是单个资源, 不应该这样 api/id/users, 而应该是 api/users/{userId}.
(资源名是否复数还是根据个人习惯吧).
例如 api/department/{departmentId}/emoloyees, 这就表示了department (部门)和 员工(employee)之前是主从关系.
而 api/department/{departmentId}/emoloyees/{employeeId}, 就表示了该部门下的某个员工.
而过滤, 排序等不是资源, 所以这样写 api/users/orderby/username 是不正确的.
过滤排序这类的参数是可以作为查询参数传递进来的, 正确的写法应该是: api/users?orderby=username.
但是有时候, RPC风格的方法调用很难映射成规范的资源命名, 所以有时可以打破规范 例如 api/users/{userId}/totalsalaries.
如果使用int型作为ID的话, 大部分时候是没有问题的, 但是如果您使用的数据库的ID是自增整型的, 如果你替换数据库了, 然后把原有数据迁移到新数据库了, 那么现有数据的ID就会发生变化, 那么相当于所有的资源的地址发生了变化, 这就违反了这个:
资源的URI应该永远都是一样的.
所以GUID应该作为ID来使用. (但是我为了省事, 还是使用自增int作为ID吧
如对本文有疑问,请在下面进行留言讨论,广大热心网友会与你互动!! 点击进行留言回复
Net Core Web Api项目与在NginX下发布的方法
asp.net core3.1 引用的元包dll版本兼容性问题解决方案
IdentityServer4实现.Net Core API接口权限认证(快速入门)
ASP.NET Core MVC通过IViewLocationExpander扩展视图搜索路径的实现
网友评论