注册

接口设计

大家好,我是二营长,日拱一卒无有尽,功不唐捐终入海。这里是Java学习小站,关注我,每天进步一点点!


接口的重要性:

在日常的开发中,在需求确定之后,后端同学首先要做的就是定义接口,接口定义完成之后,前端的同学就可以看接口文档和后端进行同步开发了。接口文档的作用还有很多:

  1. 沟通:开发、测试和其他人员之间的沟通渠道;它定义了接口的规范和预期行为,确保所有团队成员对接口的功能和使用方式有共同的理解。
  2. 效率:开发人员可以根据文档准确地了解如何调用接口、传递参数以及处理响应。这减少了开发过程中的试错和猜测,使开发人员能够更加专注于业务逻辑的实现。
  3. 并行开发:当多个开发人员同时工作在一个项目中时,接口文档允许他们独立地开发和测试各自的模块。通过定义清晰的接口规范,团队成员可以并行工作,而无需过多的交流和依赖。
  4. 代码质量:清晰的接口先行的方式,可以促使开发人员编写更健壮和可靠的代码。接口定义之后,整个交互过程就了然于胸了。
  5. 方便集成:当不同的系统或团队之间需要进行集成时,接口文档起到了关键的作用。通过提供准确和详细的接口规范,文档可以帮助团队避免集成过程中的误解和错误,降低集成风险。
  6. 支持第三方开发:如果你的应用程序或服务允许第三方开发者使用你的接口,好的接口文档是必不可少的。它为第三方开发者提供了准确的接口描述和示例代码,促进了他们与你的系统进行集成和开发扩展。

工作中常见的维护接口文档的方式:

使用Swagger、YApi等自动化接口管理平台。

Swagger和YApi等工具提供了自动化生成接口文档的功能,它们可以通过解析代码注释、接口定义或接口调用等方式,自动生成接口文档。这样可以减少手动编写和维护文档的工作量,同时确保文档与实际接口保持同步。

这些自动化管理平台还提供了其他有用的功能,例如接口测试、Mock数据生成、权限管理等。它们通常具备用户友好的界面和交互,可以方便团队成员共同编辑和维护接口文档,提高团队协作效率。

怎么设计好一个接口

我曾经遭遇过面试官,疯狂追问接口使如何设计的,虽然这是日常工作的一部分,但是很遗憾我没有表述清楚。

大部分的互联网项目都选择使用HTTP请求的方式进行交互的。

HTTP请求的组成

HTTP请求通常包括以下几个部分:

  1. 请求行(Request Line):包括请求方法(如GET、POST)、请求的URL路径和协议版本(如HTTP/1.1)。

  2. 请求头部(Request Headers):包括多个键值对,用于传递请求的元信息。常见的请求头部字段包括Host、User-Agent、Content-Type、Authorization等。

  3. 空行(Blank Line):请求头部与请求体之间需要有一个空行,用于分隔请求头部和请求体。

  4. 请求体(Request Body):对于某些请求方法(如POST),可以包含请求的内容,如表单数据、JSON数据等。对于其他请求方法(如GET),请求体通常为空。

HTTP请求报文的方式:

HTTP请求报文的方式主要有以下几种:

  1. GET请求:GET请求通过URL参数传递数据,将请求参数附加在URL的末尾,以?开头,多个参数使用&分隔。GET请求的数据会明文显示在URL中,适合用于请求获取资源,对数据安全性要求较低的情况。

  2. POST请求:POST请求将数据放在请求体中传递,适合用于提交表单、上传文件等操作。POST请求的数据不会显示在URL中,相对于GET请求更加安全,但需要在请求头中指定请求体的内容类型(Content-Type)。

  3. PUT请求:PUT请求用于更新(全量替换)指定资源的信息。PUT请求将数据放在请求体中传递,类似于POST请求,但PUT请求要求对指定的资源进行完全替换,而不是部分修改。

  4. PATCH请求:PATCH请求用于部分更新指定资源的信息。PATCH请求将数据放在请求体中传递,用于对资源进行局部修改,而不是全量替换。PATCH请求可以避免对整个资源进行完全替换的开销。

  5. DELETE请求:DELETE请求用于删除指定的资源。DELETE请求通常不包含请求体,而是通过URL指定要删除的资源的路径。

RESTful API 接口规范

REST(Representational State Transfer)是一种软件架构风格和设计原则,用于构建分布式系统和网络应用程序。RESTful是基于REST原则定义的一组规范和约束,用于设计和开发Web API接口。

在RESTful规范中,可以理解为一切即资源,所有请求都是对资源的操作或查询。

RESTful架构中的几个核心概念:

  1. 资源(Resources):每种资源都有一个唯一的统一资源定位符(URI),用于标识和定位该资源。URI代表资源的地址或唯一识别符。

  2. 表现层(Representation):资源的表现层是指将资源具体呈现出来的形式。URI只表示资源的位置,而资源的具体表现形式可以通过HTTP请求的头信息中的Accept和Content-Type字段来指定。这两个字段描述了资源的表现层。

  3. 状态转化(State Transfer):客户端要操作服务器上的资源,需要通过某种方式触发服务器端的状态转变。这种转变是建立在表现层之上的,因此称为"表现层状态转化"。

在RESTful架构中,客户端使用HTTP协议中的四个表示操作方式的动词(GET、POST、PUT、DELETE)来实现状态转化。这些动词分别对应着四种基本操作:GET用于获取资源,POST用于新建资源(也可用于更新资源),PUT用于更新资源,DELETE用于删除资源。

简要总结:

  • 每个URI代表一种资源。
  • 客户端和服务器之间传递资源的表现层。
  • 客户端通过HTTP动词对服务器端资源进行操作,实现表现层状态转化。

举个例子

API命名规范:面向资源命名

当设计符合RESTful规范的接口时,可以在URL路径中添加版本号或者命名空间,以提供更好的可扩展性和可维护性。

获取所有文章:

请求方法:GET

URL路径:/api/articles

示例请求:GET /api/articles

示例响应:

{
  "articles": [
    {
      "id"1,
      "title""RESTful 接口设计",
      "content""这是一篇关于RESTful接口设计的文章。"
    },
    {
      "id"2,
      "title""RESTful 接口实现",
      "content""这是一篇关于RESTful接口实现的文章。"
    }
  ]
}

获取单个文章:

请求方法:GET

URL路径:/api/articles/{id}

示例请求:GET /api/articles/1

示例响应:

{
  "id"1,
  "title""RESTful 接口设计",
  "content""这是一篇关于RESTful接口设计的文章。"
}

创建文章:

请求方法:POST

URL路径:/api/articles

示例请求:

POST /api/articles
Content-Type: application/json

{
  "title""新的文章",
  "content""这是一个全新的文章。"
}

示例响应:

{
  "id"3,
  "title""新的文章",
  "content""这是一个全新的文章。"
}

更新文章:

请求方法:PUT

URL路径:/api/articles/{id}

示例请求:

PUT /api/articles/1
Content-Type: application/json

{
  "title""更新后的文章",
  "content""这是一篇更新后的文章。"
}

示例响应:

{
  "id"1,
  "title""更新后的文章",
  "content""这是一篇更新后的文章。"
}

删除文章:

请求方法:DELETE

URL路径:/api/articles/{id}

示例请求:DELETE /api/articles/1

示例响应:

{
  "message""文章已成功删除。"
}

通过在URL路径中添加/api前缀,可以更好地组织和管理接口,区分不同的功能模块或者版本。这种方式可以提高接口的可扩展性和可维护性,同时也符合常见的API设计实践。

定义统一的请求或响应参数

请求参数:

在定义请求参数时,可以根据具体的业务需求和安全考虑,包括一些常见的参数类型和参数名称。下面是一些常见的请求参数定义:

  1. 查询参数(Query Parameters):这些参数通常包含在URL中,以键值对的形式出现,用于过滤、排序、分页等操作。例如,对于获取文章列表的接口,可以接受page和limit参数来指定返回的页数和每页的数量。

  2. 路径参数(Path Parameters):这些参数通常嵌入在URL路径中,用于标识资源的唯一标识符或其他信息。例如,对于获取单个文章的接口,可以将文章ID作为路径参数,如/articles/{id}。

  3. 请求体参数(Request Body Parameters):这些参数通常包含在请求的消息体中,以JSON、XML或其他格式进行传输,用于传递复杂或大量的数据。例如,对于创建文章的接口,可以将文章的标题、内容等信息作为请求体参数。

  4. 请求头参数(Request Header Parameters):这些参数包含在HTTP请求的头部中,用于传递与请求相关的元数据或控制信息。例如,可以使用Authorization头部参数传递身份验证信息,如token。

对于特定的安全需求,例如身份验证和授权,常见的请求参数包括:

  • Token:用于身份验证和授权的令牌,通常是一个字符串。可以将Token作为请求头参数(如Authorization),请求体参数或查询参数的一部分,具体取决于API设计的需求和标准。

  • API密钥(API Key):用于标识和验证应用程序的身份,通常是一个长字符串。API密钥可以作为请求头参数、请求体参数或查询参数的一部分,以确保只有授权的应用程序可以访问API。

  • 时间戳(Timestamp):用于防止重放攻击和确保请求的时效性,通常是一个表示当前时间的数字或字符串。时间戳可以作为请求头参数、请求体参数或查询参数的一部分。

这些请求参数的具体定义和使用方式应根据你的应用程序需求和安全策略来确定。确保在设计API时考虑到安全性、一致性和易用性。另外,建议参考相关的API设计规范和最佳实践,如OpenAPI规范或RESTful API设计指南。

响应参数

接口响应实例:

{
  "version""string",
  "msg""string",
  "code"200,
  "error""false",
  "data": {},
  "values": {}
}

这个示例中包含了以下参数:

  • version:表示接口版本的字符串。可以用于标识接口的版本号,方便后续的版本控制和兼容性处理。

  • msg:用于提供接口响应的描述信息的字符串。可以包含有关请求处理结果的额外说明或其他相关信息。

  • code:表示请求的处理结果状态码的整数值。一般情况下,200表示成功,其他状态码用于表示不同的错误或结果。

  • error:表示请求处理是否出错的布尔值。当发生错误时,可以将其设置为true,否则设置为false。

  • data:表示接口响应的具体数据的对象。可以包含接口处理结果的数据,例如获取的用户信息、文章内容等。

  • values:表示其他相关数值或附加信息的对象。可以用于传递一些额外的关键值或辅助信息。


                    END

日拱一卒无有尽,功不唐捐终入海。这里是Java学习小站,关注我,每天进步一点点!

0 个评论

要回复文章请先登录注册