本文所需的一些预备知识可以看这里: http://www.cnblogs.com/cgzl/p/9010978.html 和 http://www.cnblogs.com/cgzl/p/9019314.html

本文介绍的是使用ASP.NET Core建立Richardson成熟度为2级的伪RESTful web API, 支持CRUD操作.

使用的项目是(右键另存为, 然后把后缀名改为zip): https://images2018.cnblogs.com/blog/986268/201805/986268-20180516191053536-1701412182.jpg

RESTful API 资源 (Resource) 的命名指导规范

首先, 资源应该使用名词, 它是个东西, 不是动作.

例如:

  • api/getusers 就是不正确的.
  • GET api/users 就是正确的
  • GET api/users/{userId}.

所以资源应该使用的是名词.

如果是非分层结构的资源, 那么它不应该这样命名: 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.

应该使用什么类型作为ID

如果使用int型作为ID的话, 大部分时候是没有问题的, 但是如果您使用的数据库的ID是自增整型的, 如果你替换数据库了, 然后把原有数据迁移到新数据库了, 那么现有数据的ID就会发生变化, 那么相当于所有的资源的地址发生了变化, 这就违反了这个:

资源的URI应该永远都是一样的.

所以GUID应该作为ID来使用. (但是我为了省事, 还是使用自增int作为ID吧

最新文章

  1. Mosquitto搭建Android推送服务番外篇一:各种报错解决
  2. windows目录选择 文件选择 文件保存对话框
  3. WCF初探-8:WCF服务承载 (上)
  4. 济南学习D2T2__数学分析题
  5. 在Windows下使用Nodist进行Node版本控制
  6. Swift 正式开源, 包括 Swift 核心库和包管理器
  7. TV
  8. POJ1182并查集
  9. 【转】Angularjs Controller 间通信机制
  10. NSData、NSString 、 NSFileManager
  11. 理解ROS话题
  12. 【转】gcc/g++ 如何支持c11 / c++11标准编译
  13. 多项目中SVN权限管理精辟解析
  14. Sanatorium
  15. 区别client、offset、scroll系列以及event的几个距离属性
  16. 听翁恺老师mooc笔记(1)--为何选择学习C
  17. Http的定义及其基本概念介绍
  18. input type = file 在部分安卓手机上无法调起摄像头和相册
  19. LOJ #2196「SDOI2014」LIS
  20. Python3集合

热门文章

  1. pop弹簧动画实现
  2. java学习日记-基础-列出2~100内的素数
  3. Day15 Javascipt内容补充
  4. 学习spring中遇见的问题
  5. Spring Boot【快速入门】
  6. 分享一下在aspx页面弹框的设置代码
  7. C# 使用SmtpClient发送Email
  8. 分布式任务调度——quartz + spring + 数据库
  9. 和同门一起做的PHP网站
  10. Django入门一之安装及项目创建