Days
- 00. 简介
- 01. 初识 Python
- 02. 语言元素
- 03. 分支结构
- 04. 循环结构
- 05. 构造程序逻辑
- 06. 函数和模块的使用
- 07. 字符串和常用数据结构
- 08. 面向对象编程基础
- 09. 面向对象进阶
- 10. 图形用户界面和游戏开发
- 11. 文件和异常
- 12. 字符串和正则表达式
- 13. 进程和线程
- 14. 网络编程入门和网络应用开发
- 15. 图像和办公文档处理
- 16 20. Python 语言进阶
- 21 30. Web 前端概述
- 31 35. 玩转 Linux 操作系统
- 36. 关系型数据库和 MySQL 概述
- 37. SQL 详解之 DDL
- 38. SQL 详解之 DML
- 39. SQL 详解之 DQL
- 40. SQL 详解之 DCL
- 41. MySQL 新特性
- 42. 视图、函数和过程
- 43. 索引
- 44. Python接入MySQL数据库
- 45. 大数据平台和HiveSQL
- 46. Django快速上手
- 47. 深入模型
- 48. 静态资源和 Ajax 请求
- 49. Cookie 和 Session
- 50. 制作报表
- 51. 日志和调试工具栏
- 52. 中间件的应用
- 53. 前后端分离开发入门
- 54. RESTful 架构和 DRF 入门
- 55. RESTful 架构和 DRF 进阶
- 56. 使用缓存
- 57. 接入三方平台
- 58. 异步任务和定时任务
- 59. 单元测试
- 60. 项目上线
- 61. 网络数据采集概述
- 62. 用 Python 获取网络资源 1
- 62. 用 Python 解析 HTML 页面 2
- 63. Python 中的并发编程 1
- 63. Python 中的并发编程 2
- 63. Python 中的并发编程 3
- 63. 并发编程在爬虫中的应用
- 64. 使用 Selenium 抓取网页动态内容
- 65. 爬虫框架 Scrapy 简介
- 66. 数据分析概述
- 67. 环境准备
- 68. NumPy 的应用 1
- 69. NumPy 的应用 2
- 70. NumPy 的应用 3
- 71. NumPy 的应用 4
- 72. 深入浅出 pandas 1
- 73. 深入浅出 pandas 2
- 74. 深入浅出 pandas 3
- 75. 深入浅出 pandas 4
- 76. 深入浅出 pandas 5
- 77. 深入浅出 pandas 6
- 78. 数据可视化 1
- 79. 数据可视化 2
- 80. 数据可视化 3
- 81. 人工智能和机器学习概述
- 82. k 最近邻分类
- 83. 决策树
- 83. 推荐系统实战 1
- 84. 贝叶斯分类
- 85. 支持向量机
- 86. K 均值聚类
- 87. 回归分析
- 88. 深度学习入门
- 89. PyTorch 概述
- 90. PyTorch 实战
- 91. 团队项目开发的问题和解决方案
- 92. Docker 容器技术详解
- 93. MySQL 性能优化
- 94. 网络 API 接口设计
- 95. 使用 Django 开发商业项目
- 96. 软件测试和自动化测试
- 97. 电商网站技术要点剖析
- 98. 项目部署上线和性能调优
- 99. 面试中的公共问题
- 100. Python 面试题实录
公开课
番外篇
94. 网络 API 接口设计
目前许多的Web应用和移动应用都使用了前后端分离的开发模式,前后端分离简单的说就是前端或移动端通过网络API接口和后台进行交互,获得接口中提供的数据并负责用户界面的渲染。API是应用程序的编程接口的缩写,网络API通常指的是基于一个URL(统一资源定位符)可以访问到的资源,也就是说通过这个URL我们就可以请求服务器对某个资源进行操作并返回操作的结果。大家可以想想,网络API接口不也是一种封装吗,简单的说就是将复杂的业务逻辑隐藏在简单的API接口中。
URL的通用格式如下所示:
协议://用户名:口令@主机:端口/路径1/.../路径N/资源名
说明:URL中的用户名(有可能不需要提供用户名)、口令(有可能不需要提供口令)、端口(有可能使用默认端口)、路径(资源有可能直接位于根路径
/
下)并不是必需的部分,可以根据需要进行设置。
网络API通常基于HTTP或HTTPS进行访问,基于HTTP/HTTPS最大的好处就在于访问起来非常的简单方便,而且可以跨语言、跨应用进行访问和互操作。
设计原则
关键问题
为移动端或者PC端设计网络API接口一个非常重要的原则是:根据业务实体而不是用户界面或操作来设计API接口。如果API接口的设计是根据用户的操作或者界面上的功能设置来设计,随着需求的变更,用户界面也会进行调整,需要的数据也在发生变化,那么后端开发者就要不停的调整API,或者给一个API设计出多个版本,这些都会使项目的开发和维护成本增加。我们可以将业务实体理解为服务器提供的资源,而URL就是资源的定位符(标识符),这种方式是最为简单自然的。对于相对复杂的用户操作,我们可以提供一个“门面”(设计模式中的“门面模式”),通过该“门面”把多个接口的功能组装起来即可。
下面是某个网站开放API的接口,可以看出API的设计是围绕业务实体来进行的,而且都做到了“见名知意”。
评论 | |
---|---|
comments/show | 获取某条微博的评论列表 |
comments/by_me | 自己的评论列表 |
comments/to_me | 收到的评论列表 |
comments/mentions | @了自己的评论列表 |
comments/create | 创建一条评论 |
comments/destroy | 删除一条评论 |
comments/reply | 回复一条评论 |
需要说明的是,上面的API接口并不是REST风格的。REST是一种网络应用架构风格,被认为最适合分布式的网络应用。关于REST的知识,可以阅读阮一峰的《理解RESTful架构》以及《RESTful API设计指南》,当然这两篇文章大家也要批判的阅读,因为上面阐述的观点并不完全正确,有些内容甚至是自相矛盾的。
API接口返回的数据通常都是JSON或XML格式,XML这种数据格式目前基本已经被弃用了。对于JSON格式的数据,我们需要做到不要返回null这的值,因为这样的值一旦处置失当,会给前端和移动端开发带来不必要的麻烦(因为开发者有可能会使用强类型语言)。要解决这个问题可以从源头入手,在设计数据库的时候,尽量给每个字段都加上“not null”约束或者设置合理的默认值约束。
其他问题
- 更新提示问题:设计一个每次使用系统首先要访问的API,该API会向移动端返回系统更新的相关信息,这样就可以提升用户更新App了。
- 版本升级问题:API版本升级时应该考虑对低版本的兼容,同时要让新版本和旧版本都能够被访问,可以在URL中包含版本信息或者在将版本号放在HTTP(S)协议头部,关于这个问题有很多的争论,有兴趣的可以看看stack overflow上面对这个问题的讨论。
- 图片尺寸问题:移动端对于一张图片可能需要不同的尺寸,可以在获取图片时传入尺寸参数并获取对应的资源;更好的做法是直接使用云存储或CDN(直接提供了图片缩放的功能),这样可以加速对资源的访问。
文档撰写
下面以设计评论接口为例,简单说明接口文档应该如何撰写。
首先,我们可以定义全局返回状态码。
返回码 | 返回信息 | 说明 |
---|---|---|
10000 | 获取评论成功 | |
10001 | 创建评论成功 | |
10002 | 无法创建评论 | 创建评论时因违反审核机制而无法创建 |
10003 | 评论已被删除 | 查看评论时评论因不和谐因素已被删除 |
10004 | …… | …… |
获取文章评论。
GET
/articles/{article-id}/comments/
开发者:王大锤
最后更新时间:2018年8月10日
标签:v 1.0
接口说明:获取指定文章的所有评论
使用帮助:默认返回20条数据,需要在请求头中设置身份标识(key)
请求参数:
| 参数名 | 类型 | 是否必填 | 参数位置 | 说明 | | ------ | ------ | -------- | -------- | ------------------------------------ | | page | 整数 | 否 | 查询参数 | 页码,默认值1 | | size | 整数 | 否 | 查询参数 | 每次获取评论数量(10~100),默认值20 | | key | 字符串 | 是 | 请求头 | 用户的身份标识 |
响应信息:
{ "code": 10000, "message": "获取评论成功", "page": 1, "size": 10, "totalPage": 35, "contents": [ { "userId": 1700095, "nickname": "王大锤", "pubDate": "2018年7月31日", "content": "小编是不是有病呀", /* ... */ }, { "userId", 1995322, "nickname": "白元芳", "pubDate": "2018年8月2日", "content": "楼上说得好", /* ... */ } ] /* ... */ }
新增文章评论。
POST
/articles/{article-id}/comments
开发者:王大锤
最后更新时间:2018年8月10日
标签:v 1.0
接口说明:为指定的文章创建评论
使用帮助:暂无
请求参数:
| 参数名 | 类型 | 是否必填 | 参数位置 | 说明 | | ------- | ------ | -------- | -------- | ---------- | | userId | 字符串 | 是 | 消息体 | 用户ID | | key | 字符串 | 是 | 请求头 | 用户的令牌 | | content | 字符串 | 是 | 消息体 | 评论的内容 |
响应信息:
{ "code": 10001, "message": "创建评论成功", "comment": { "pubDate": "2018年7月31日", "content": "小编是不是有病呀" /* ... */ } /* ... */ }
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论