Restful 是什么??
网络上的所有事物都被抽象为资源 每个资源都有一个的资源标识符 同一个资源具有多种表现形式(xml,json 等) 对资源的各种操作不会改变资源标识符 所有的操作都是无状态的
/getCustomers
/getCustomersByName
/getCustomersByPhone
/getNewCustomers
/verifyCredit
/saveCustomer
/updateCustomer
/deleteCustomer
/getCustomers
/getAllCustomer
/getCustomerList
/getPagedCustomer
/queryCustomers
/queryAllCustomers
/queryCustomerList
...
获取系统资源,主要包括读取资源和资源描述信息。 对系统资源进行变更,主要包括写入资源,对已有资源状态的变更,删除已有资源。
GET: 获取目标资源。 HEAD: 获取(传输)目标资源的元数据信息。该方法与 GET 相同,但是不传递内容体。 POST: 创建新资源,对于复杂查询而言,提交查询表单给查询服务也是常用 POST 的(当然其他几个能做的它也能做)。 PUT: 替换已有资源(整体)。 PATCH: 修改已有资源(局部)。 DELETE: 删除资源。
GET /Api/Users/{id}
POST /Api/Orders
POST /Api/Orders/{id}/OrderItems
POST /Api/Orders/{id}/OrderItems/{itemId}/OrderItemAttachments
POST /Api/Orders/{id}/OrderItems/{itemId}/OrderItemAttachments/{}/...
...
POST /Api/Orders
{
"locationId": 1,
"productIds": [
1,
2,
3
]
}
POST /Api/Orders/{id}/OrderItems
{
"productIds": [
4,
5,
6
]
}
POST /Api/OrderItemAttachments
{
"orderItemId": 1,
"fileUrl": "xxx"
}
POST /Api/Orders
POST /Api/Orders/{id}/OrderItems
POST /Api/OrderItemAttachment
PUT /Api/Orders/{id}
PUT /Api/Orders/{id}/OrderItems/{itemId}
PUT /Api/OrderItemAttachments/{id}
PATCH /Api/Orders/{id}/Address
PATCH /Api/Orders/{id}/OrderItems/{id}/Amount
PATCH /Api/OrderItemAttachments/{id}/FileUrl
DELETE /Api/Orders/{id}
DELETE /Api/Orders/Batches
DELETE /Api/Orders/{id}/OrderItems/{id}
DELETE /Api/OrderItemAttachments/{id}
POST /Api/Invites/emailTemplate
PATCH /Api/Invites/{id}/Sendmail //Sendmail 作为邮件服务资源
PATCH /Api/Notifications/{id}/MessageStatus
PATCH /Api/Notifications/MessageStatus/batches
PATCH /Api/Orders/{id}/OrderItem/{itemId}/PayStatus
POST /Api/Orders/exports //返回导出资源
POST /Api/exportServices //提交给导出服务资源
POST /Api/exportServices/Sendmail
POST /Api/InviteParseServices //提交给解析服务资源
...
POST /Api/Account/Login
POST /Api/Account/Logout
POST /Api/Account/Register
POST /Api/Accounts
POST /Api/OnlineUsers
Authorization,不直接在 URI 中传递参数
DELETE /Api/OnlineUsers
GET /Api/Orders
GET /Api/Orders/{id}
GET /Api/Orders/{id}/OrderItems
GET /Api/Orders/{id}/OrderItems/{id}
筛选
GET /Api/Orders?Name=xxx&LocationId=xxx
分页
GET /Api/Orders?Page=1&Limit=10
也可以拆分成如下两个此处资源为 Page
GET /Api/Orders/Page?Page=1&Limit=10
GET /Api/Orders/PageCount?Page=1&Limit=10
排序
GET /Api/Orders?Sort=Name%20DESC
GET /Api/Orders?Sort=Name%20DESC,CreationTime%20ASC
// UI 上需要知道某个资源是否存在
GET /Api/Orders?name=xxx
HEAD /Api/Orders?name=xxx
能够查询到状态码返回 204
找不到状态码返回 404
// 文件下载
GET /Api/OrderFiles/{id}/Url
// 报表分析(将报表分析的结果作为虚拟资源)
GET /Api/AnalyseResults
// 返回指定条件下的总数
GET /Api/Locations/{id}/OrderCount?Status[]&Status[]=2&CreationTime=2022-05-01
// UI 上下拉框所需要的基础数据
GET /Api/Locations/Names?page=1&limit=30&search=xxx
{
"id": "xxx",
"name": "xxx"
}
// 获取近的循环周期
GET /Api/Plans/{id}/LatestCycleDate
// 获取近的记录(根据时间,状态过滤后的条)
GET /Api/Orders/Latest
...
PATCH /Api/Invites/{id}/Approval
PATCH /Api/Invites/{id}/Decline
PATCH /Api/Invites/{id}/Reject
...
{
"code":200,
"message":"",
"data":{
}
}
Informational responses (100–199) Successful responses (200–299) Redirection messages (300–399) Client error responses (400–499) Server error responses (500–599)
不考虑版本,内部使用、短暂的生命周期下不考虑资源的变更或是直接对资源本身进行了换新如此变更到新的 url 上。 为每个资源的 URI 添加一个版本号。
GET /Api/v2/Orders/{id}
作为查询字符串参数来指定资源的版本
GET /Api/Orders/{id}?version=2
在 http 的 header 中增加自定标头设置版本号。
GET /Api/Orders/{id}
Custom-Header: version=2
Level 0: 定义一个 URI,所有操作是对此 URI 发出的 POST 请求。 Level 1: 为各个资源单独创建 URI。 Level 2: 使用 HTTP 方法来定义对资源执行的操作。 Level 3: 使用超媒体(HATEOAS: 「H」ypermedia 「A」s 「T」he 「E」ngine 「O」f 「A」pplication 「S」tate,参见 HATEOAS - Wikipedia )。
相关文章