文档章节

再谈RestAPI最佳实践

山哥
 山哥
发布于 2014/06/09 11:33
字数 2192
阅读 253
收藏 20

本文由 伯乐在线 - Justin Wu 翻译自 javacodegeeks

近一年半,我参与了两到三个项目的工作,这些项目涉及到大量供“外部”使用的Rest API,稍后我们会看到为什么要将“外部”这个词放在引号之中。在项目工作期间,我不得不对这些API进行反复地设计,再设计和重构,这篇文章是我对Rest API最佳实践的一些个人看法,希望读者能够从中获益。


更好、更早地设计

对于很多语言来说,实现Rest Service是一项极其微不足道的任务。换言之,无论你选择什么底层框架,只要辅以少量配置和代码,你可以在一小时之内就拥有一个Rest?Service。虽然对于缺乏经验的人来说,这确实很方便,但它也很容易让你迅速写出一个质量低下的API。因此,在你编写代码之前,先留出一分钟的时间思考一下,试着去设计你的API,花足够的时间去理解业务范畴,判断客户端需要从你的系统中获取什么。举个例子,如果你的系统是针对一群硬币收藏家所建立的数据库,此时你需要决定的是:你是否允许客户端添加新的硬币,或者仅仅允许取出原有的硬币;客户需要什么样的查询方式;如果遇上涉及大量数据检索的请求,你如何处理它?尽早地回答这些问题能够帮助你开发出更贴近用户需求的API。


名称与方法

现在已经很有多关于资源(Resource)命名和组织的讨论了,在这里我基于自己的经验再老调重弹一下,以下是三种易于遵循的规范。

1. 只使用名词:举个例子,如果你想提供一项在数据库中搜索硬币的服务,要避免将端点(Endpoint)命名为/searchCoins或/findCoins或/getAllCoins 等等,一个简单的/coins就已经足够了,当客户端发送一个GET请求的时候,可以获得所有有效硬币的集合。类似的,如果你想提供一项在数据库中添加硬币的服务,要避免使用诸如/addCoin或/saveCoin或/insertCointToDatabase这样的名称,你可以使用与上面相同的资源名称,要改变的仅仅是用POST请求代替GET请求。同样地,对于更新硬币,可以使用PUT请求。

2. 如果需要获取单个硬币,又应该怎么做呢?我所建议的最佳方式是在端点中加入一个参数,比如说客户端需要拿到一个ID是20的硬币,那么发送一个请求到/coins/20就足够了。我们再来看一个更复杂的例子,如果要让客户端能够为每个硬币添加一张图片,一个快速而丑陋的方式是/addCoinImage或/addNewImageToCoin等等,一个稍好一点的方式是/coins/addImage,但是正如我之前所说的,不应该有任何动词存在。还记得我们之前提到的获取某种硬币的方法吗?我们可以将其稍微增强一下,发送POST请求给/coins/20/images如何?目前看起来很不错。不过天下没有完美的事物,假设一下,如果我们要让一些超级用户能够从系统中删除硬币,根据我们之前的讨论,一个简单的DELETE请求发送给/coins/{id}就足够了,但是请你想一下,如果{id}仅仅是COINS表中的一个顺序编号,那会产生多大的问题?某人可以轻易地一个接一个的发送DELETE请求,最后系统中所有的数据全没了。我想说的重点是,使用标识符作为请求参数是不错,但是前提是这些标识符必须很难猜测或根本无法猜测。所以,如果你想要用一串序号去确定一个实体,那就忘了这种实现吧。我的建议是,不要使用资源参数,直接发送一个DELETE请求给/coins,结合一个request body(比如json),其中含有足够的参数能够定位所要被删除的实体即可。

3. 尽可能使用特定领域的名称。如果你的业务域中有一群硬币收藏家(Coin Collectors),那么当你设计API的时候,应当使用collectors这个词,而不是users或accounts。要避免使用一些意义过于宽泛的名称,这些名称不能表示什么,到了客户端又容易产生误解。对于请求参数的命名,道理也是一样的。另外,强烈建议给请求参数取一个尽可能短,同时又有意义的名称,举个例子,如果你想要查找在某一指定年份发行的硬币,一个很赞的参数名称是issueYear,比较典型的反例是:year(意义不明确),yearOfFirstIssue(包含无用信息)。


错误处理和响应

对于这个话题,我的经验是让客户端在每次发送请求后,无论结果是成功还是失败,都能获得相同格式的json响应,这将会给客户端处理带来极大的帮助。举个例子,你想要添加一个新的硬币,向/coins发送POST请求,一个成功的响应包含以下json文档:

{
     "meta":{
      "code":200
   },
   "data":{
      "coinId":"a7sad-123kk-223"
   }
}

一个错误的响应可能是这样的:

{
     "meta":{
      "code":60001,
      "error":"Can not add coin",
      "info":"Missing one ore more required fields"
   },
   "data":{
   }
}

请注意,对所有可能的结果(成功或失败),json响应的文档都具备相同的结构,其中有两种基本元素:meta和data,meta包含结果信息,在出错的情况下,其中还会包含一个特殊的错误码(error code),在错误码之后,”error”表示出错的内容,”info”表示出错的具体描述;data是可选的,包含从服务器返回的所有数据,就拿上面的例子来说,当添加硬币成功后,服务器会返回一个唯一的自动生成的标识符,如果有错误,这项就为空。这种做法的优势是,对于同一个API的各种服务类型和结果,客户端都可以采用相同的方式进行处理。此外,当有意外情况发生时,我们也可以传递一些额外的信息,正如上面例子中所展示的,”error”传达信息,”info”记录日志。我们还有一种选择,可以基于错误码去处理响应,只要明确每个数字的含义即可,请注意这些数字并非http状态码,你依然要为每个请求返回正确的http状态码(如400、401等)。


在我们讨论下一节之前,我想强调另一件值得重视的事,假设我们不允许删除硬币,但是客户端尝试向/coins/{id}发送一个DELETE请求,通常情况下Web容器会返回一个405的状态码,但我发现,如果我们对这些响应进行过滤并返回相同的json文档,会很有帮助。比如我们可以返回:

{
     "meta":{
      "code":405,
      "error":"Method not allowed for the /coins/{id} resource",
      "info":"Method DELETE is not allowed for that resource. Available methods : GET, POST, OPTIONS"
   },
   "data":{
   }
}

这比原来好多了,不是吗?现在,响应内容不但包含原有的信息(405状态码),还通知客户端该资源可用的方法。


文档

最后但也是最重要的一点,花一点时间,提供一份专业的、对开发人员友好的文档,并保证及时更新,一份过期文档的危害性比没有文档更甚。你可以使用一些开源免费的工具对你的API进行文档化。再好一点的做法是,对每一项资源的使用方式都能提供范例,对成功或错误的响应都能提供预期结果。不要忘了,在最后要记录下每一个错误码并提供完整的信息,这样客户端才能在错误发生时做出反应,有一些客户端不会理会你的响应内容,它们会根据你的错误码自行提供信息。


我还有若干个更为实用的建议待写,特别是关于API的版本控制和安全性方面的建议,但我想它们更适合在另一篇博文中进行探讨。


本文转载自:http://blog.jobbole.com/70511/

共有 人打赏支持
山哥

山哥

粉丝 245
博文 351
码字总数 136465
作品 0
南京
程序员
私信 提问
基于 Spring + Dubbo 开发分布式REST服务实战

本课程主要是使用 Spring技术栈 + dubbo 开发一个类似当当的图书电商后台的实战教程。 课程特点: 1.课程的技术体系足够系统、全面以及细致:课程中涉及的主要技术包括: Spring IO (依赖版本...

登录404
2017/05/17
1K
3
RestAPI设计疑问

平台:java 1. 对于RestApi 设计时是否需要把model(实体类)暴露给使用方 业界一般怎么做的 如果不暴露 仅仅依靠契约 那么提供方每一次修改 对于使用方来说岂不是要了命 而且使用方八成也会...

ZeRur_
2016/09/17
266
2
【年度盛典】Gdevops上海站收官前瞻,精彩不可错过!

经过杭州、北京、广州三站的成功举办,2016年11月18日,全球敏捷运维峰会(Gdevops)将在上海带来本年度的收官之作,这将是一场集结技术先锋领袖与上千IT精英的顶尖盛会,也是一场萃取架构、...

DBAplus社群
2016/09/19
0
0
SpringBoot项目web端请求其他的微服务提供的RestApi

SpringBoot项目web端请求其他的微服务提供的RestApi 目前我想到的有两种方案: 1. 在web端写controller采用RestTemplate方式请求其他的微服务RestApi,然后页面请求web端体提供的controller,...

微风徐徐
2016/11/20
847
2
RestApi 封装问题

RestApi 封装问题。 一般你们使用java调用restApi时是如何封装的啊,会考虑重传么? 求点类似的代码,优雅点的。

Y292450104
2016/04/20
117
0

没有更多内容

加载失败,请刷新页面

加载更多

hive load insert

本文主要是翻译Hive官网关于Load的解释,原文来源于:https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DML#LanguageManualDML-Loadingfilesintotables 介绍 Hive Load语句......

hblt-j
7分钟前
0
1
spring cloud中微服务之间的调用以及eureka的自我保护机制

我自己搭建了一个客户端微服务: 所以现在有两个微服务,我们所实现的就是微服务1和微服务2之间的调用 注册中心就不用多说了,具体看一下两个微服务 在project-solr中的constroller中: @Res...

架构师springboot
9分钟前
0
0
从源码角度理解Java设计模式——装饰者模式

一、饰器者模式介绍 装饰者模式定义:在不改变原有对象的基础上附加功能,相比生成子类更灵活。 适用场景:动态的给一个对象添加或者撤销功能。 优点:可以不改变原有对象的情况下动态扩展功...

我叫刘半仙
15分钟前
0
0
Java中前台接收后台List数据并循环打印

在Java后端获取到了数据,然后我们需要传到前端页面展现出来。 方法有两种: 方法一: 后端: request.setAttribute("list",list); 前端: <%ArrayList list = (ArrayList) request.get...

小_橙_子
23分钟前
1
0
Java:字节流和字符流(输入流和输出流)

什么是流 如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring,MyBatis,Netty源码分析的朋友可以加我的Java高级交流:854630135,群里有阿里大牛直播讲解技术,以及Java大型互...

编程SHA
24分钟前
1
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部