URL的通用格式如下所示:

    网络API通常基于HTTP或HTTPS进行访问,基于HTTP/HTTPS最大的好处就在于访问起来非常的简单方便,而且可以跨语言、跨应用进行访问和互操作。

    关键问题

    为移动端或者PC端设计网络API接口一个非常重要的原则是:根据业务实体而不是用户界面或操作来设计API接口。如果API接口的设计是根据用户的操作或者界面上的功能设置来设计,随着需求的变更,用户界面也会进行调整,需要的数据也在发生变化,那么后端开发者就要不停的调整API,或者给一个API设计出多个版本,这些都会使项目的开发和维护成本增加。我们可以将业务实体理解为服务器提供的资源,而URL就是资源的定位符(标识符),这种方式是最为简单自然的。对于相对复杂的用户操作,我们可以提供一个“门面”(设计模式中的“门面模式”),通过该“门面”把多个接口的功能组装起来即可。

    下面是某个网站开放API的接口,可以看出API的设计是围绕业务实体来进行的,而且都做到了“见名知意”。

    需要说明的是,上面的API接口并不是REST风格的。REST是一种网络应用架构风格,被认为最适合分布式的网络应用。关于REST的知识,可以阅读阮一峰的以及《RESTful API设计指南》,当然这两篇文章大家也要批判的阅读,因为上面阐述的观点并不完全正确,有些内容甚至是自相矛盾的。

    API接口返回的数据通常都是JSONXML格式,XML这种数据格式目前基本已经被弃用了。对于JSON格式的数据,我们需要做到不要返回null这的值,因为这样的值一旦处置失当,会给前端和移动端开发带来不必要的麻烦(因为开发者有可能会使用强类型语言)。要解决这个问题可以从源头入手,在设计数据库的时候,尽量给每个字段都加上“not null”约束或者设置合理的默认值约束。

    其他问题

    1. 更新提示问题:设计一个每次使用系统首先要访问的API,该API会向移动端返回系统更新的相关信息,这样就可以提升用户更新App了。
    2. 图片尺寸问题:移动端对于一张图片可能需要不同的尺寸,可以在获取图片时传入尺寸参数并获取对应的资源;更好的做法是直接使用云存储或CDN(直接提供了图片缩放的功能),这样可以加速对资源的访问。

    文档撰写

    下面以设计评论接口为例,简单说明接口文档应该如何撰写。

    首先,我们可以定义全局返回状态码。

    返回码 返回信息 说明
    10000 获取评论成功
    10001 创建评论成功
    10002 无法创建评论 创建评论时因违反审核机制而无法创建
    10003 评论已被删除 查看评论时评论因不和谐因素已被删除
    10004 …… ……
    1. GET

      开发者:王大锤

      最后更新时间:2018年8月10日

      标签:v 1.0

      接口说明:获取指定文章的所有评论

      使用帮助:默认返回20条数据,需要在请求头中设置身份标识(key)

      请求参数:

      | 参数名 | 类型 | 是否必填 | 参数位置 | 说明 | | ——— | ——— | ———— | ———— | —————————————————— | | page | 整数 | 否 | 查询参数 | 页码,默认值1 | | size | 整数 | 否 | 查询参数 | 每次获取评论数量(10~100),默认值20 | | key | 字符串 | 是 | 请求头 | 用户的身份标识 |

      响应信息: