前言

随着互联网行业的兴起,开发模式已逐步转换为微服务自治:小团队开发微服务,然后通过Restful接口相互调用。开发者们越来越渴望能够使用一种“官话”进行流畅的沟通,甚至实现多种编程语言系统的自动化交互。

开放API战略(Open API Initiativev)于2017年1月发表声明,2月发布实现草案,经过反复讨论, 标准API规范OAS(OpenAPI-Specification)3.0版本在2017年6月诞生。

本文通过对OAS 3.0的分析解读,希望抛砖引玉,和大家一起了解OAS如何定义一种机器和人都能够发现与识别的规范,使得OpenAPI消费者可使用最小数量的实现逻辑来理解远程服务。

OpenAPI-Specification规范架构

OAS 3.0架构中将OpenAPI赋予了以下8个模块的定义,其中黄色模块为必选字段,绿色模块为可选字段:

各个主要模块工作流如下所示:

以下重点说明用户获取OAS API信息的三个必选部分:

1.API基本信息

用户查询获取OpenAPI的基本定义及信息,涉及以下两个模块内容:

openapi

是否必选:必选

对象类型:String

类似于XML声明(<?xml version="1.0"?> ),用于设定文件应该使用哪一种规范进行解析。

info

是否必选:必选

对象类型:Info Object

这个模块主要提供API的元数据。

以下为一个Info Object样例:

title: Sample Pet Store App    #必须,应用名称
description: This is a sample server for apetstore. #应用的描述
termsOfService: http://example.com/terms/ #应用的服务条款连接
contact: #应用提供商的联系方式
name: API Support
url: http://www.example.com/support
email: support@example.com
license: #应用所遵循的协议
name: Apache 2.0
url: http://www.apache.org/licenses/LICENSE-2.0.html
version: 1.0.1 #应用版本

2.目标服务器信息

用户查询获取服务器的基本定义及信息,涉及以下模块信息:

servers

是否必选:必选

对象类型:[Server Object]

这个模块主要提供和目标服务器的连接信息,如果这个模块没有定义url,根据规范会自动生成一个url为/的Server Object。

例如:

servers:
- url: https://development.gigantic-server.com/v1 #必选,
description: Development server #非必选,url描述

3.API路径及定义

查询API具体参数,涉及OAS剩余的模块,本文主要介绍paths和components模块。

paths

是否必选:必选

对象类型:Paths Object

这个模块主要提供OpenAPI所在的目标服务器的连接信息,如果这个模块没有定义,根据规范会自动生成一个url为/的Server Object。通过多级定义,分别确定API的paths/method,并且通过$ref引用comonents模块中的定义,可以复用响应码等相关信息。对于携带body体的请求类型,requestBody可以提供example(或数组examples),这是非常灵活的(可以传入一个完整的例子,一个参考,甚至是一个URL的例子)。

例如:

/pets:        #URL
get: #方法,get/post/..
description: Returns all pets . #描述
responses: #响应模块
'': #返回码为200,可以使用通配符定义响应
description: A list of pets. #响应描述
content: #Content字段
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/pet' #引用componets components 是否必选:非必选 对象类型:Components Object 这个模块主要提供每个OpenAPI自定义的字段定义,这部分定义的对象往往被paths中具体API进行引用: −响应 responses −参数 parameters −示例 examples −请求体 requestBodies −标题 headers −链接 links −回调 callbacks −模式 schemas −安全体系 securitySchemes 以下为一个Components Object样例: components:
schemas: #协议定义
Category:
type: object
properties:
id:
type: integer
format: int64
name:
type: string
Tag:
type: object
properties:
id:
type: integer
format: int64
name:
type: string
parameters: #参数定义
skipParam:
name: skip
in: query
description: number of items to skip
required: true
schema:
type: integer
format: int32
limitParam:
name: limit
in: query
description: max records to return
required: true
schema:
type: integer
format: int32
responses: #返回信息定义
NotFound:
description: Entity not found.
IllegalInput:
description: Illegal input for operation.
GeneralError:
description: General Error
content:
application/json:
schema:
$ref: '#/components/schemas/GeneralError'
securitySchemes:
api_key:
type: apiKey
name: api_key
in: header
petstore_auth: #认证定义
type: oauth2
flows:
implicit:
authorizationUrl: http://example.org/api/oauth/dialog
scopes:
write:pets: modify pets in your account
read:pets: read your pets

如何使用OAS 设计可扩展的OpenAPI

OpenAPI规范包含一组有关如何设计REST API的强制性准则,首推协议优先的方法,而非实现优先,因此需要首先设计API接口,然后实现协定接口的代码。

如何实现一个优雅的API是一个非常具有挑战性的工作,开发者需要在庞大的后端系统的支持下,通过合适的方式将API暴露出去,除去单词拼写,路径设计等以外,设计优良的OpenAPI往往具有以下特性:

单一职责

单一职责是软件工程中一条著名的原则,实际在设计API时应确保每个API具有单一核心的职责,当某个API职责发生改变时不应该导致其他API发生故障和风险。OAS中不同的API可以在paths模块中引用多个schema,当我们设计新的API或者扩展原有API功能时,如果发现多个API多次引用相同schema,需重点审视每个API是否仍然保持单一职责。

抽象API

合适的抽象API 与业务无关的,更通用,而且方便扩展。 具体的API接口设计能解决特定的问题,但是在系统的扩展性和普遍适用性上则相应欠缺,因此需要针对特定的场景分析,避免over-designed(过度设计)和under-engineering(懒惰设计)。

举个简单的例子,我们设计一个paths为/dog的API,那么这个API返回的是具体dog的相关信息,而如果我们进行抽象设计一个paths为/pet的API,将dog作为参数配置在components的parameters中,这样该API的扩展性进行了提升,后续扩展其他宠物比如cat的业务可以在不改变API路径的基础上进行开发,只需要更新component的parameters即可。

收敛API

提供给用户的OpenAPI最好支持批量数据处理,而不是让用户一次一次地调用。通过考虑多个API间的关联性,让用户体会到API的简洁性。举例来说,如果用户有可能在调用 API2之前需要API1的结果,那么API提供者应该把API1和API2进行包装。这会减轻用户的记忆负担,API收敛需要符合最少知识的原则,作为用户应该对他所使用的系统有最少的了解,而不是过多介入到系统的细节中,因此在设计API时候,在满足用户诉求的情况下,components模块字段越少越好。设计者往往容易在收敛API时候出现无法保证单一职责的原则的情况,好的设计需要在两者之间取得一个平衡,聚焦于最终的目的:让使用者快好省的用起来。

扩展机制

在设计API时需要考虑未来可扩展性,为后续API兼容历史API提供支持。一方面便于开发者自身增加功能,另一方面用户也能参与进来,共建API生态。通过设计定义OAS,可以方便的按照OAS架构设计出面向对象、扩展性良好的API。

版本控制

版本控制其实是扩展的一部分,鉴于大量项目在版本控制方面都做的比较糟糕,诸如随心所欲的版本命名、前后格式不一致的版本设定、没有规范的功能迭代,因此在大版本号不变的情况下,需要保障API向前兼容。当API的大版本号改动时,意味着API整体有大的改动,很可能不兼容之前的API,同时可以提醒用户需要查询API更新文档进行适配,否则用户可能在更新API之后出现各种各样难以预测的故障。反之,如果修改小版本号则意味着这是个向前兼容的优化升级,用户可以在例行更新中采用新的API。这种和用户约定好的默契,可以激发用户采用新版本的热情,而不是永远不升级依赖。

面向扩展开发

在通过OAS定义完相关信息之后,优雅的OpenAPI在开发过程中应着重思考API的可配置性,API的实现应该面向修改开放的,因此需要将相关诸如参数校验、字段长度等配置项进行抽取,在提供默认配置项的前提下可配置可修改,同时应当允许配置项的新增,例如引入java的可变参数类型等,这样当OAS文档进行修改时,可以尽可能的较少整体API实现的变动量。

以上列举了优雅的OpenAPI所具有的部分特性,与其说OAS设计规范是一个强制的法则,不如说是一种引导式框架,开发者通过遵循规范从而实现高效的敏捷迭代。

当完成OpenAPI的设计开发之后,我们需要将API托管到合适的平台上进行能力开放,优秀的平台减少API提供者的工作量,抽取公共能力使API提供者更加专注于业务功能开发。华为云的API网关集成了监控、流控、负载均衡等一系列功能,可以为开发者提供高性能、高可用的API 托管服务,实现个人、企业API能力的快速开放。

关于API网关的详情,可以点击这里免费体验

参考文献:

《OpenAPI Specification》 :https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#componentsObject

《Microsoft REST API Guidelines》 :https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md

《API 设计》 :https://docs.microsoft.com/zh-cn/azure/architecture/best-practices/api-design

《从达标到卓越 —— API 设计之道》 :http://taobaofed.org/blog/2017/02/16/a-guide-to-api-design/

基于OAS设计可扩展OpenAPI的更多相关文章

  1. 基于Spring的可扩展Schema进行开发自定义配置标签支持

    一.背景 最近和朋友一起想开发一个类似alibaba dubbo的功能的工具,其中就用到了基于Spring的可扩展Schema进行开发自定义配置标签支持,通过上网查资料自己写了一个demo.今天在这里 ...

  2. 基于Spring设计并实现RESTful Web Services(转)

    基于Spring设计并实现RESTful Web Services 在本教程中,你将会使用Spring来创建一个具有生产力的RESTful网络服务. 为什么用RESTful网络服务? 从和Amazon ...

  3. 基于Golang设计一套微服务架构[转]

      article- @嘟嘟噜- May/26/2018 18:35:30 如何基于Golang设计一套微服务架构 微服务(Microservices),这个近几年我们经常听到.那么现在市面上的的微服 ...

  4. 基于easyui的验证扩展

    基于easyui的验证扩展 ##前言 自己做项目也有好几年的时间了,一直没有时间整理自己的代码,趁春节比较闲,把自己以前的代码整理了一篇.这是基于easyui1.2.6的一些验证扩展,2012年就开始 ...

  5. 基于easyui的webform扩展(续)

    基于easyui的webform扩展(续) 回顾 <前端基于easyui的mvc扩展>.<前端基于easyui的mvc扩展(续)>.<基于easyui的webform扩展 ...

  6. 基于easyui的webform扩展

    基于easyui的webform扩展 回顾 <前端基于easyui的mvc扩展>.<前端基于easyui的mvc扩展(续)>前两篇介绍了mvc内如何基于easyui进行扩展,在 ...

  7. 前端基于easyui的mvc扩展(续)

    前端基于easyui的mvc扩展(续) 回顾及遗留问题 上一篇讲解了基于easyui的mvc扩展的基本实现,已经降低了在mvc内使用easyui的难度,但是仍然还有一些问题: 当我们要给生成的控件设置 ...

  8. 基于 HtmlHelper 的自定义扩展Container

    基于 HtmlHelper 的自定义扩展Container Intro 基于 asp.net mvc 的权限控制系统的一部分,适用于对UI层数据呈现的控制,基于 HtmlHelper 的扩展组件 Co ...

  9. 使用Asp.Net Core MVC 开发项目实践[第四篇:基于EF Core的扩展2]

    上篇我们说到了基于EFCore的基础扩展,这篇我们讲解下基于实体结合拉姆达表达式的自定义更新以及删除数据. 先说下原理:其实通过实体以及拉姆达表达式生成SQL语句去执行 第一种更新扩展: 自定义更新字 ...

随机推荐

  1. 【转】MFC 自定义edit 限制输入十六进制内容 响应复制粘贴全选剪切的功能

    参考地址:MFC 自定义edit 限制输入内容 响应复制粘贴全选剪切的功能   Ctrl组合键ASCII码 ^Z代表Ctrl+z                     ASCII值 控制字符  AS ...

  2. EasyUI入门,DataGrid(数据表格)

    搭建EasyUI 1.进入官网,下载EasyUI的程序包.地址:http://www.jeasyui.com/download/list.php 2.先导入css样式,引入程序包 3.进入EasyUI ...

  3. 将java project打包成jar包,web project 打包成war包的几种演示 此博文包含图片

    转: http://blog.csdn.net/christine_ruan/article/details/7491559 http://developer.51cto.com/art/200907 ...

  4. ionic提供的配色方案

    .light #ffffff .stable #f8f8f8 .positive #387ef5 .calm #11c1f3 .balanced #33cd5f .energized #ffc900 ...

  5. mui.openWindow的html5+和web传参的兼容

    mui.openWindow兼容web&plus环境下的页面传参 背景介绍 刚刚好要写个微信公众号和html5+兼容的项目 发现总是用localStorage传参不是事啊 太不优雅了 想了想还 ...

  6. Spider-Scrapy css选择器提取数据

    首先我们来说说css选择器:其实在上面的概述:和scrapy相关的函数就这么三个而已:response.css("css表达式").extract().extract_first( ...

  7. python 用 PIL 模块 画验证码

    PIL 简单绘画 def get_code_img(request): from PIL import Image, ImageDraw, ImageFont import random def ra ...

  8. admin源码之url设计

    如何实现批量设计url? 1.创建Django项目 2.新建app01 和 app02 3.在models.py中创建模型 4.在settings.py中完成数据库配置.app配置等 5.数据库迁移 ...

  9. Spring AOP配置简单记录(注解及xml配置方式)

    在了解spring aop中的关键字(如:连接点(JoinPoint).切入点(PointCut).切面(Aspact).织入(Weaving).通知(Advice).目标(Target)等)后进行了 ...

  10. 【03】AJAX 向服务器发送请求

    AJAX 向服务器发送请求   创建 XMLHttpRequest 对象后,就可以向服务器发送请求了. XMLHttpRequest 对象的 open() 方法和 send() 方法用来向服务器发送请 ...