RESTful API 设计规范

最新推荐文章于 2023-08-01 14:23:44 发布
最新推荐文章于 2023-08-01 14:23:44 发布
阅读量174 收藏 1
点赞数
文章标签： json 运维 php

转载来自：https://juejin.im/post/5b30ef0ee51d4558dd699414#heading-12

本文是为 腾讯大渝网 API开发规范拟定的一个beta版，文章大量参考了目前比较常见的RESETful API设计。

为了更好的讨论规范带来的争议及问题，现已把该文档整理并开源到 github。

关于「能愿动词」的使用

为了避免歧义，文档大量使用了「能愿动词」，对应的解释如下：

  •  必须 (MUST)：绝对，严格遵循，请照做，无条件遵守；
  •  一定不可 (MUST NOT)：禁令，严令禁止；
  •  应该 (SHOULD)：强烈建议这样做，但是不强求；
  •  不该 (SHOULD NOT)：强烈不建议这样做，但是不强求；
  •  可以 (MAY)和可选 (OPTIONAL)：选择性高一点，在这个文档内，此词语使用较少；

协议

在通过API于后端服务通信的过程中，应该使用HTTPS协议。

API Root URL

API的根入口点应尽可能保持足够简单，这里有两个常见的URL根例子：

  •  api.example.com/*
  •  example.com/api/*

如果你的应用很庞大或者你预计它将会变的很庞大，那应该将API放到子域下。这种做法可以保持某些规模化上的灵活性。

Versioning

所有的API必须保持向后兼容，你必须在引入新版本API的同时确保旧版本API仍然可用。所以应该为其提供版本支持。

目前比较常见的两种版本号形式：

在 URL 中嵌入版本编号

api.example.com/v1/*

这种做法是版本号直观、易于调试；另一种做法是，将版本号放在HTTP Header头中：

通过媒体类型来指定版本信息

Accept: application/vnd.example.com.v1+json

其中vnd表示Standards Tree标准树类型，有三个不同的树:x，prs和vnd。你使用的标准树需要取决于你开发的项目

  •  未注册的树（x）主要表示本地和私有环境
  •  私有树（prs）主要表示没有商业发布的项目
  •  供应商树（vnd）主要表示公开发布的项目

后面几个参数依次为应用名称（一般为应用域名）、版本号、期望的返回格式。

至于具体把版本号放在什么地方，这个问题一直存在很大的争议，但由于我们大多数时间都在使用Laravel开发，应该使用 dingo/api 来快速构建应用，它采用第二种方式来管理API版本，并且已集成了标准的HTTP Response。

Endpoints

端点就是指向特定资源或资源集合的URL。在端点的设计中，你必须遵守下列约定：

  •  URL 的命名必须全部小写
  •  URL 中资源（resource）的命名必须是名词，并且必须是复数形式
  •  必须优先使用Restful类型的 URL
  •  URL 中不能出现-，必须用下划线_代替
  •  URL必须是易读的
  •  URL一定不可暴露服务器架构

来看一个反例

再来看一个正列

HTTP 动词

对于资源的具体操作类型，由HTTP动词表示。常用的HTTP动词有下面五个（括号里是对应的SQL命令）。

  •  GET（SELECT）：从服务器取出资源（一项或多项）。
  •  POST（CREATE）：在服务器新建一个资源。
  •  PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
  •  PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。
  •  DELETE（DELETE）：从服务器删除资源。

其中

1 删除资源必须用DELETE方法
2 创建新的资源必须使用POST方法
3 更新资源应该使用PUT方法
4 获取资源信息必须使用GET方法

针对每一个端点来说，下面列出所有可行的HTTP动词和端点的组合

请求方法URL描述
GET/zoos列出所有的动物园(ID和名称，不要太详细)
POST/zoos新增一个新的动物园
GET/zoos/{zoo}获取指定动物园详情
PUT/zoos/{zoo}更新指定动物园(整个对象)
PATCH/zoos/{zoo}更新动物园(部分对象)
DELETE/zoos/{zoo}删除指定动物园
GET/zoos/{zoo}/animals检索指定动物园下的动物列表(ID和名称，不要太详细)
GET/animals列出所有动物(ID和名称)。
POST/animals新增新的动物
GET/animals/{animal}获取指定的动物详情
PUT/animals/{animal}更新指定的动物(整个对象)
PATCH/animals/{animal}更新指定的动物(部分对象)
GET/animal_types获取所有动物类型(ID和名称，不要太详细)
GET/animal_types/{type}获取指定的动物类型详情
GET/employees检索整个雇员列表
GET/employees/{employee}检索指定特定的员工
GET/zoos/{zoo}/employees检索在这个动物园工作的雇员的名单(身份证和姓名)
POST/employees新增指定新员工
POST/zoos/{zoo}/employees在特定的动物园雇佣一名员工
DELETE/zoos/{zoo}/employees/{employee}从某个动物园解雇一名员工

Filtering

如果记录数量很多，服务器不可能都将它们返回给用户。API应该提供参数，过滤返回结果。下面是一些常见的参数。

  •  ?limit=10：指定返回记录的数量
  •  ?offset=10：指定返回记录的开始位置。
  •  ?page=2&per_page=100：指定第几页，以及每页的记录数。
  •  ?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。
  •  ?animal_type_id=1：指定筛选条件

所有URL参数必须是全小写，必须使用下划线类型的参数形式。

经常使用的、复杂的查询应该标签化，降低维护成本。如

GET /trades?status=closed&sort=sortby=name&order=asc # 可为其定制快捷方式 GET /trades/recently_closed

Authentication

应该使用OAuth2.0的方式为 API 调用者提供登录认证。必须先通过登录接口获取Access Token后再通过该token调用需要身份认证的API。

Oauth 的端点设计示列

  •  RFC 6749 /token
  •  Twitter /oauth2/token
  •  Fackbook /oauth/access_token
  •  Google /o/oauth2/token
  •  Github /login/oauth/access_token
  •  Instagram /oauth/authorize

客户端在获得access token的同时必须在响应中包含一个名为expires_in的数据，它表示当前获得的token会在多少秒后失效。

{ "access_token": "token....", "token_type": "Bearer", "expires_in": 3600 }

客户端在请求需要认证的API时，必须在请求头Authorization中带上access_token。

Authorization: Bearer token...

当超过指定的秒数后，access token就会过期，再次用过期/或无效的token访问时，服务端应该返回invalid_token的错误或401错误码。

HTTP/1.1 401 Unauthorized Content-Type: application/json Cache-Control: no-store Pragma: no-cache { "error": "invalid_token" }

Laravel 开发中，应该使用 JWT 来为管理你的 Token，并且一定不可在api中间件中开启请求session。

Response

所有的API响应，必须遵守HTTP设计规范，必须选择合适的HTTP状态码。一定不可所有接口都返回状态码为200的HTTP响应，如：

HTTP/1.1 200 ok Content-Type: application/json Server: example.com { "code": 0, "msg": "success", "data": { "username": "username" } }

或

HTTP/1.1 200 ok Content-Type: application/json Server: example.com { "code": -1, "msg": "该活动不存在", }

下表列举了常见的HTTP状态码

状态码描述
1xx代表请求已被接受，需要继续处理
2xx请求已成功，请求所希望的响应头或数据体将随此响应返回
3xx重定向
4xx客户端原因引起的错误
5xx服务端原因引起的错误

只有来自客户端的请求被正确的处理后才能返回2xx的响应，所以当 API 返回2xx类型的状态码时，前端必须认定该请求已处理成功。

必须强调的是，所有API一定不可返回1xx类型的状态码。当API发生错误时，必须返回出错时的详细信息。目前常见返回错误信息的方法有两种：

1、将错误详细放入HTTP响应首部；

X-MYNAME-ERROR-CODE: 4001 X-MYNAME-ERROR-MESSAGE: Bad authentication token X-MYNAME-ERROR-INFO: http://docs.example.com/api/v1/authentication

2、直接放入响应实体中；

HTTP/1.1 401 Unauthorized Server: nginx/1.11.9 Content-Type: application/json Transfer-Encoding: chunked Cache-Control: no-cache, private Date: Sun, 24 Jun 2018 10:02:59 GMT Connection: keep-alive {"error_code":40100,"message":"Unauthorized"}

考虑到易读性和客户端的易处理性，我们必须把错误信息直接放到响应实体中，并且错误格式应该满足如下格式：

{ "message": "您查找的资源不存在", "error_code": 404001 }

其中错误码（error_code）必须和HTTP状态码对应，也方便错误码归类，如：

HTTP/1.1 429 Too Many Requests Server: nginx/1.11.9 Content-Type: application/json Transfer-Encoding: chunked Cache-Control: no-cache, private Date: Sun, 24 Jun 2018 10:15:52 GMT Connection: keep-alive {"error_code":429001,"message":"你操作太频繁了"}
HTTP/1.1 403 Forbidden Server: nginx/1.11.9 Content-Type: application/json Transfer-Encoding: chunked Cache-Control: no-cache, private Date: Sun, 24 Jun 2018 10:19:27 GMT Connection: keep-alive {"error_code":403002,"message":"用户已禁用"}

应该在返回的错误信息中，同时包含面向开发者和面向用户的提示信息，前者可方便开发人员调试，后者可直接展示给终端用户查看如：

{ "message": "直接展示给终端用户的错误信息", "error_code": "业务错误码", "error": "供开发者查看的错误信息", "debug": [ "错误堆栈，必须开启 debug 才存在" ] }

下面详细列举了各种情况 API 的返回说明。

200 ok

200状态码是最常见的HTTP状态码，在所有 成功 的GET请求中，必须返回此状态码。HTTP响应实体部分必须直接就是数据，不要做多余的包装。

错误示例：

HTTP/1.1 200 ok Content-Type: application/json Server: example.com { "user": { "id":1, "nickname":"fwest", "username": "example" } }

正确示例：

1、获取单个资源详情

{ "id": 1, "username": "godruoyi", "age": 88, }

2、获取资源集合

[
    { "id": 1, "username": "godruoyi", "age": 88, }, { "id": 2, "username": "foo", "age": 88, } ]

3、额外的媒体信息

{ "data": [ { "id": 1, "avatar": "https://lorempixel.com/640/480/?32556", "nickname": "fwest", "last_logined_time": "2018-05-29 04:56:43", "has_registed": true }, { "id": 2, "avatar": "https://lorempixel.com/640/480/?86144", "nickname": "zschowalter", "last_logined_time": "2018-06-16 15:18:34", "has_registed": true } ], "meta": { "pagination": { "total": 101, "count": 2, "per_page": 2, "current_page": 1, "total_pages": 51, "links": { "next": "http://api.example.com?page=2" } } } }

其中，分页和其他额外的媒体信息，必须放到meta字段中。

201 Created

当服务器创建数据成功时，应该返回此状态码。常见的应用场景是使用POST提交用户信息，如：

  •  添加了新用户
  •  上传了图片
  •  创建了新活动

等，都可以返回201状态码。需要注意的是，你可以选择在用户创建成功后返回新用户的数据

HTTP/1.1 201 Created Server: nginx/1.11.9 Content-Type: application/json Transfer-Encoding: chunked Date: Sun, 24 Jun 2018 09:13:40 GMT Connection: keep-alive { "id": 1, "avatar": "https:\/\/lorempixel.com\/640\/480\/?32556", "nickname": "fwest", "last_logined_time": "2018-05-29 04:56:43", "created_at": "2018-06-16 17:55:55", "updated_at": "2018-06-16 17:55:55" }

也可以返回一个响应实体为空的HTTP Response如：

HTTP/1.1 201 Created Server: nginx/1.11.9 Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Date: Sun, 24 Jun 2018 09:12:20 GMT Connection: keep-alive

这里我们应该采用第二种方式，因为大多数情况下，客户端只需要知道该请求操作成功与否，并不需要返回新资源的信息。

202 Accepted

该状态码表示服务器已经接受到了来自客户端的请求，但还未开始处理。常用短信发送、邮件通知、模板消息推送等这类很耗时需要队列支持的场景中；

返回该状态码时，响应实体必须为空。

HTTP/1.1 202 Accepted Server: nginx/1.11.9 Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Date: Sun, 24 Jun 2018 09:25:15 GMT Connection: keep-alive

204 No Content

该状态码表示响应实体不包含任何数据，其中：

  •  在使用DELETE方法删除资源 成功 时，必须返回该状态码
  •  使用PUT、PATCH方法更新数据 成功 时，也应该返回此状态码
HTTP/1.1 204 No Content Server: nginx/1.11.9 Date: Sun, 24 Jun 2018 09:29:12 GMT Connection: keep-alive

3xx 重定向

所有API一定不可返回3xx类型的状态码。因为3xx类型的响应格式一般为下列格式：

HTTP/1.1 302 Found Server: nginx/1.11.9 Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Cache-Control: no-cache, private Date: Sun, 24 Jun 2018 09:41:50 GMT Location: https://example.com Connection: keep-alive <!DOCTYPE html> <html> <head> <meta charset="UTF-8" /> <meta http-equiv="refresh" content="0;url=https://example.com" /> <title>Redirecting to https://example.com</title> </head> <body> Redirecting to <a href="https://example.com">https://example.com</a>. </body> </html>

API一定不可返回纯HTML结构的响应；若一定要使用重定向功能，应该返回一个响应实体为空的3xx响应，并在响应头中加上Location字段:

HTTP/1.1 302 Found Server: nginx/1.11.9 Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Date: Sun, 24 Jun 2018 09:52:50 GMT Location: https://godruoyi.com Connection: keep-alive

400 Bad Request

由于明显的客户端错误（例如，请求语法格式错误、无效的请求、无效的签名等），服务器应该放弃该请求。

当服务器无法从其他 4xx 类型的状态码中找出合适的来表示错误类型时，都必须返回该状态码。

HTTP/1.1 400 Bad Request Server: nginx/1.11.9 Content-Type: application/json Transfer-Encoding: chunked Cache-Control: no-cache, private Date: Sun, 24 Jun 2018 13:22:36 GMT Connection: keep-alive {"error_code":40000,"message":"无效的签名"}

401 Unauthorized

该状态码表示当前请求需要身份认证，以下情况都必须返回该状态码。

  •  未认证用户访问需要认证的 API
  •  access_token 无效/过期

客户端在收到401响应后，都应该提示用户进行下一步的登录操作。

HTTP/1.1 401 Unauthorized Server: nginx/1.11.9 Content-Type: application/json Transfer-Encoding: chunked WWW-Authenticate: JWTAuth Cache-Control: no-cache, private Date: Sun, 24 Jun 2018 13:17:02 GMT Connection: keep-alive "message":"Token Signature could not be verified.","error_code": "40100"}

403 Forbidden

该状态码可以简单的理解为没有权限访问该请求，服务器收到请求但拒绝提供服务。

如当普通用户请求操作管理员用户时，必须返回该状态码。

HTTP/1.1 403 Forbidden Server: nginx/1.11.9 Content-Type: application/json Transfer-Encoding: chunked Cache-Control: no-cache, private Date: Sun, 24 Jun 2018 13:05:34 GMT Connection: keep-alive {"error_code":40301,"message":"权限不足"}

404 Not Found

该状态码表示用户请求的资源不存在，如

  •  获取不存在的用户信息 （get /users/9999999）
  •  访问不存在的端点

都必须返回该状态码，若该资源已永久不存在，则应该返回410响应。

405 Method Not Allowd

当客户端使用的HTTP请求方法不被服务器允许时，必须返回该状态码。

如客户端调用了POST方法来访问只支持 GET 方法的 API

该响应必须返回一个Allow头信息用以表示出当前资源能够接受的请求方法的列表。

HTTP/1.1 405 Method Not Allowed Server: nginx/1.11.9 Content-Type: application/json Transfer-Encoding: chunked Allow: GET, HEAD Cache-Control: no-cache, private Date: Sun, 24 Jun 2018 12:30:57 GMT Connection: keep-alive {"message":"405 Method Not Allowed","error_code": 40500}

406 Not Acceptable

API在不支持客户端指定的数据格式时，应该返回此状态码。如支持JSON和XML输出的API被指定返回YAML格式的数据时。

Http 协议一般通过请求首部的 Accept 来指定数据格式

408 Request Timeout

客户端请求超时时必须返回该状态码，需要注意的时，该状态码表示 客户端请求超时，在涉及第三方API调用超时时，一定不可返回该状态码。

409 Gonfilct

该状态码表示因为请求存在冲突无法处理。如通过手机号码提供注册功能的API，当用户提交的手机号已存在时，必须返回此状态码。

HTTP/1.1 409 Conflict Server: nginx/1.11.9 Content-Type: application/json Transfer-Encoding: chunked Cache-Control: no-cache, private Date: Sun, 24 Jun 2018 12:19:04 GMT Connection: keep-alive {"error_code":40900,"message":"手机号已存在"}

410 Gone

和404类似，该状态码也表示请求的资源不存在，只是410状态码进一步表示所请求的资源已不存在，并且未来也不会存在。在收到410状态码后，客户端应该停止再次请求该资源。

413 Request Entity Too Large

该状态码表示服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。

此种情况下，服务器可以关闭连接以免客户端继续发送此请求。

如果这个状况是临时的，服务器应该返回一个Retry-After的响应头，以告知客户端可以在多少时间以后重新尝试。

414 Request-URI Too Long

该状态码表示请求的URI长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。

415 Unsupported Media Type

通常表示服务器不支持客户端请求首部Content-Type指定的数据格式。如在只接受JSON格式的API中放入XML类型的数据并向服务器发送，都应该返回该状态码。

该状态码也可用于如：只允许上传图片格式的文件，但是客户端提交媒体文件非法或不是图片类型，这时应该返回该状态码：

HTTP/1.1 415 Unsupported Media Type Server: nginx/1.11.9 Content-Type: application/json Transfer-Encoding: chunked Cache-Control: no-cache, private Date: Sun, 24 Jun 2018 12:09:40 GMT Connection: keep-alive {"error_code":41500,"message":"不允许上传的图片格式"}

429 Too Many Request

该状态码表示用户请求次数超过允许范围。如API设定为60次/分钟，当用户在一分钟内请求次数超过 60 次后，都应该返回该状态码。并且也应该在响应首部中加上下列头部：

X-RateLimit-Limit: 10 请求速率（由应用设定，其单位一般为小时/分钟等，这里是 10次/5分钟） X-RateLimit-Remaining: 0 当前剩余的请求数量 X-RateLimit-Reset: 1529839462 重置时间 Retry-After: 120 下一次访问应该等待的时间（秒）

列子

HTTP/1.1 429 Too Many Requests Server: nginx/1.11.9 Content-Type: application/json Transfer-Encoding: chunked X-RateLimit-Limit: 10 X-RateLimit-Remaining: 0 X-RateLimit-Reset: 1529839462 Retry-After: 290 Cache-Control: no-cache, private Date: Sun, 24 Jun 2018 11:19:32 GMT Connection: keep-alive {"message":"You have exceeded your rate limit.","error_code":42900}

必须为所有的 API 设置 Rate Limit 支持。

500 Internal Server Error

该状态码必须在服务器出错时抛出，对于所有的500错误，都应该提供完整的错误信息支持，也方便跟踪调试。

503 Service Unavailable

该状态码表示服务器暂时处理不可用状态，当服务器需要维护或第三方API请求超时/不可达时，都应该返回该状态码，其中若是主动关闭 API 服务，应该在返回的响应首部加上Retry-After头部，表示多少秒后可以再次访问。

HTTP/1.1 503 Service Unavailable Server: nginx/1.11.9 Content-Type: application/json Transfer-Encoding: chunked Cache-Control: no-cache, private Date: Sun, 24 Jun 2018 10:56:20 GMT Retry-After: 60 Connection: keep-alive {"error_code":50300,"message":"服务维护中"}

其他HTTP状态码请参考 HTTP 状态码- 维基百科。

http://www.gitout.cn/?p=2536

 

weixin_33725722
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
后端api规范说明文档
zscd0218的博客
04-15 5896
   我们此次后端api的实现主要是按照RESTful api规范来设计的，就是符合REST架构下设计api的规范。简单的来说REST结构就是：利用URL定位资源，用HTTP动词(GET,POST,PUT,DELETE)来描述相应操作。       RESTful api主要的意义在于它可以让在不同形式的前端所接受到的用户请求能够统一的发送到一个后台并返回不同的前端。RESTful api是由后端...
Api设计规范
08-25
Java API Design Checklist，如何设计api，设计api规范
JAIN API Specifications
03-15 1403
API Specifications  Print-friendly VersionJava Application Interfaces for Communications:Java Application Containers for Communications:JAIN SIP 1.1JAIN Service Logic Execution Environment (JSLEE) 1.0
HTTP API响应数据规范整理
weixin_34357436的博客
07-28 180
2019独角兽企业重金招聘Python工程师标准>>> ...
API规范约定
songjuntao8的专栏
11-13 559
为了高效开发，节约编写文档的成本，API服务使用Swagger来描述 一、API设计原则 控制API的粒度和数量 命名要遵循简单、可读、统一原则； 优先设计API，然后编码 二、URL设计【针对后端开发】 2.1 HTTP规范 　　动词目前暂时以下面两种 HTTP 方法，对应 CRUD 操作。 GET：读取（Read） POST：新建（Create,Update,Delete） PUT：更新（Update） PATCH：更新（Update），通常是部分更新 DELETE：删除（Delete）
RESTful API设计规范.pdf
02-13
RESTful API设计规范.pdf RESTful API设计规范是指在软件架构和设计风格中，遵循一组设计原则和约束条件，以降低开发的复杂性，提高系统的可扩展性。RESTful架构的核心是面向资源，每个网址代表一种资源，因此网址...
RESTful API设计规范
03-15
### RESTful API设计规范详解 #### 一、RESTful简介 RESTful是一种广泛应用于Web服务的设计风格，全称为Representational State Transfer（表述性状态转移）。它并非一项具体的技术标准，而是一系列设计原则和约束...
RESTful API设计基础知识
07-06
RESTful API设计是构建Web服务的关键技术，遵循一套基于HTTP协议的规范，旨在提供高效、分布式的系统架构。本文将深入探讨RESTful API设计的基础知识，包括其核心概念、原则和最佳实践。 REST（Representational ...
API 接口设计规范
Brook
07-16 445
API 接口设计规范 概述 这篇文章分享 API 接口设计规范，目的是提供给研发人员做参考。 规范是死的，人是活的，希望自己定的规范，不要被打脸。 路由命名规范 动作 前缀 备注 获取 get get{XXX} 获取 get get{XXX}List 新增 add add{XXX} 修改 update update{XXX} 保存 save save{XXX} 删除 delete delete{XXX} 上传 upload upload{XXX} 发送 send send{XXX} 请求方式 请求方式 描述
Restful API 规范
Arsenal之魂的博客
05-29 533
Restful API 规范 这里我们以设备（device）的增删改查为例，介绍Restful API的规范写法 查询 HTTP GET /devices/{id} HTTP GET /devices?pageNo=1&amp;amp;pageSize=10 新增 HTTP POST /devices 更细 HTTP PUT /devices/{id} 删除 HTTP DEL...
C# 实现Rest服务接口，含实现文档
11-12
使用asp.net 实现了Rest服务接口，包括实现的文档。Rest接口返回的数据包括json、Stream等。代码结构清晰，可以直接用VS2013运行
restful API 介绍与规范
07-15
restful API 介绍与规范
如何设计一个牛逼的API接口
Java旅途
10-16 1751
在日常开发中，总会接触到各种接口。前后端数据传输接口，第三方业务平台接口。一个平台的前后端数据传输接口一般都会在内网环境下通信，而且会使用安全框架，所以安全性可以得到很好的保护。这篇文章重点讨论一下提供给第三方平台的业务接口应当如何设计？我们应该考虑哪些问题？ 主要从以上三个方面来设计一个安全的API接口。 一 安全性问题 安全性问题是一个接口必须要保证的规范。如果接口保证不了安全性，那么你的接口相当于直接暴露在公网环境中任人蹂躏。 1.1 调用接口的先决条件-token 获取token一般会涉及到几个参
API接口设计规范，看这篇就足以了
WBKJ_Noah的博客
08-01 5343
应用程序编程接口（Application Programming Interface，API接口），是应用程序重要的组成部分，就是应用程序对外提供了一个操作数据的入口，这个入口可以是一个函数或类方法，也可以是一个url地址或者一个网络地址。当客户端调用这个入口，应用程序则会执行对应代码操作，给客户端完成相对应的功能。关于限流设计、熔断设计、降级设计，目前主流网关都有相关功能（比如shenyu网关），可以不在API实现中开发这些功能。
API规范约定，让你写出高质量的API！
Mr_chen的博客
01-17 3207
一个良好的API规范约定，可以让你写出高质量的API！ API的设计原则： - 控制API的粒度和数量 - 命名要遵循简单、可读、统一原则； - 优先设计API，然后编码 - 在现在流行的微服务、敏捷开发等这些项目一般为了更高效的开发，节约编写文档的成本，API服务都会使用Swagger来生成描述。
restful api规范
qq_41891425的博客
12-05 1302
简介 restful是目前最流行的API设计规范，用于web数据接口设计 REST有主要两个核心精神： 一、使用resource来当作识别的资源，也就是使用一个URL网址来代表一个Resource 二、同一个Resource则可以有不通的Representations格式变化。这一章的路由实作了Resource概念，而Representation则是用了respond_to方法来实作 一、URL设计 1.1动词+宾语 restful的核心思想就是客户端发出的数据操作指令都是"动词+宾语" 比如 GET
API接口设计规范
QY'UniverseSpace的博客
02-19 2449
协议 http https（使用HTTPS协议，以确保交互数据的传输安全） 域名 专门的api应用使用独立域名 https://api.example.com 简单的可使用api前缀区分 https://www.example.com/api 版本控制 接口版本的控制，可以在程序发布时，不同版本的业务逻辑在一定程度上避免受到影响。 https://api.example.com/v{n} 应该将API的版本号放入URL。 采用多版本并存，增量发布的方式。 n代表版本号，分为
restful api设计规范
最新发布
09-02
RESTful API设计规范是一种用于构建可扩展、灵活且易于理解的API架构风格。以下是一些常见的RESTful API设计规范： 1. 使用合适的HTTP方法：根据操作类型选择合适的HTTP方法，如GET用于获取资源，POST用于创建资源...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值