附录

本章节属于一个比较特殊的章节，不定时更新，想到什么写什么。内容或是个人的一些感悟感想，或是对专栏中某个章节内容知识点的补充（有些知识点需要较大篇幅，不便在主体内容中体现），推荐读者阅读。

设计模式到底有什么用

设计模式，相信基本每一个开发者都或多或少听过，至于运用了多少就不得而知了。当然这小节并不打算跟大家把每个设计模式都过一遍，因为内容量太大，随便都是一本书的级别，在没有打赏的前提下，我不想写（收到一条群消息：都2020年了，沁尘的专栏还不更新）。本小节主要想和大家分享的是关于我对设计模式的理解，相信通过阅读本小节的内容，能让你对设计模式有个清晰的认识，在日后学习和运用设计模式的过程中可以少走弯路。

和大多数人一样，我一开始也是通过百度或者买书去学设计模式，在学习了一段时间之后的感触就是：设计模式太棒了，但是我好像用不着。不知道显示器前的你是不是也有这种想法，我一度很困惑，我写的项目，设计模式？不存在的。能运行吗？没问题。那我要设计干嘛呢？本来几行代码可以实现的逻辑，我可能要各种拆分和抽象，折腾出什么工厂类（工厂还分简单和抽象）。就在我百思不得其解的时候，突然一句话让我瞬间顿悟：世上无难事，只要肯放弃。是的，于是我干脆就不想这个问题了，继续写我的代码。当然故事肯定不可能这样就结束了，接下来的日子就是漫长的打脸岁月。项目两年时间里为了满足业务的增长和各种变化的需求，前前后后重构了三次，基本都是推倒重来的局面，上线后各种深夜修BUG那是家常便饭。这样的生活严重压缩了我的游戏时间，于是我开始想办法解决这个问题，我开始使用一些封装或者抽象来让各个功能模块做到尽可能的易于改动和扩展，而就在这个过程中，我发现写着写着有种似曾相似的感觉，似乎在哪看过，没错！是它！设计模式！于是乎，我赶紧翻开那尘封已久的设计模式相关书籍，再一次阅读那些曾经我“看了等于会了”的章节，瞬间有种顿悟的感觉，就在那一刻，我想明白了之前一直很困惑的那个问题的答案——不是设计模式无用，而是项目太小。当一个工程项目足够简单的时候，什么框架和面向对象、面向接口都是浮云，同理，给一个简单的工程项目引入什么设计模式那就是增加了项目的复杂度而且没收益的那种，因为根本就不需要。这里不妨回顾一下设计模式的由来，设计模式本身就是由无数业界大佬总结自己的编程经验而得出的，为了适应变化的解决方案，所以，如果你的项目本身就不会有啥变化或者变化很小，自然体会不到设计模式的作用。但是理论上不会变化的项目是不存在的(除非你这个项目已经凉了或者可有可无)，既然有变化，我们就需要改代码。众所周知，改代码是有成本和风险的，而如何控制这个成本和风险就需要开发人员借助设计模式了。作为开发者，肯定不希望老是面对不停变化的需求，无论是从划水摸鱼的角度来说还是系统稳定性来说，但这是不现实的想法。想出设计模式的前辈们也是意识到了无法阻止变化和拒绝变化，所以总结了些套路，让我们学会拥抱变化。

其实无论是从工作、学习、还是生活，个人觉得拥抱变化都是一种值得每个人拥有的态度。

看到这里，不知道读者们有没有又重新燃起了对设计模式的兴趣？当然即便没有也不要紧，只要你还写代码，你总会遇到给变化折磨得死去活来的一天，到时候你就会想到用设计模式了。最后我分享几点个人学习和运用设计模式的心得体会供读者参考：

1. 设计模式需要理论和实践结合来学习，光看理论学不会。
2. 看不同角度或者风格的设计模式书籍。
3. 理论知识似懂非懂不要紧，留个印象即可。
4. 多写项目。

提问的那点事

“提问”这一行为相信读者们都不陌生，大到生活，小到写代码，我们总会在前进的道路上遇到各种障碍。在面对障碍的时候，我们会有许多种应对方式，其中一种就是“提问”，也是最常用的一种，甚至是被滥用了的一种。为什么这么说呢？注意这里的其中一种这四个字，这里很直接的点明了这种方式不是万能的，再有就是“提问”本身是有前提和要求的，而很多人并没有意识到这些。很多人习惯性在遇到问题的时候就不假思索的提问，这也就是为什么有些人虽然提问，但是却始终得不到自己想要的答案、解决不了问题。其实说白了就是提问的方式不对，至于不对在哪，接下来作者分享几个本人亲身经历的真实例子，让读者们从另一个角度去体验这一过程。

• 不要轻易提问使用搜索引擎能解决的问题

在林间有风的官方QQ群，经常会有小伙伴提问，有时候我会复制他的问题，原原本本的放到搜索引擎中回车，然后把搜索结果的页面截图发到群里回复他，这时候会有三种情况：

1. 没人说话
2. 谢谢
3. 不好意思，我去看看

这里面我可能更期望的是第3种情况，因为下一次遇到问题的时候有很大概率会回想起这次可能不是那么好的经历，会让他暂时放弃习惯性的提问而先使用搜索引擎。有些人可能觉得我这样做有点不近人情或者装X，这里我要放出一张著名的“鸟哥语录”：

群聊对于解决问题真的是效率很低的一种方式。

都说程序员是面向谷歌/百度编程，这句话我觉得一半是玩笑一半却也是道出了事实，就个人学习经历而言，绝大数问题也确实是通过搜索引擎解决的。当然搜索引擎也有不灵的时候，这时候就需要其他手段了，手段里面就包含了我们的讨论主题——提问。看到这里，如果读者觉得作者就是想告诉你遇事先百度，不行再提问那就太年轻了，虽然你最后确实是要这么做的。但是这里我想让读者们在掌握方法之余，从更深的层次去看待这个事情。请你思考一下，或者试验一下，你先通过搜索引擎之后再提问和上来就直接提问，你提问的内容、方式以及得到的反馈会有什么不同，答案是会有很大的不同。除非你本身语言表达能力有问题或者说话实在很招人讨厌，不然绝大多数情况下你在尝试利用搜索引擎后再提问会收获一个答案或者解决思路。而另一种方式的下场则多数情况下是没有人鸟你或者像我一样给你个截图。看到这里似乎感觉充满了玄学，其实不然！问题之所以是问题，就是因为我们不懂，不知所措，无从下手，我们一开始掌握到的，都是一些很零碎或者很模糊的信息，这些已知信息在你通过搜索引擎一番折腾之后，虽然没有解决，但是往往会令信息更加准确或者说接近问题真相，这个时候再提问，你就能更好地描述问题（一个懵逼的人去描述一个自己都不知道是什么的问题肯定不会有满意的结果），别人也能更好的帮你定位到问题。

• 描述清楚你的问题

这一点其实和前面的内容有一定关联，同样是在林间有风的官方QQ群中，有些问题是出现频率比较高的，而且也有惊人的神同步，接下来作者就和大家分享一下我碰到这些提问时的内心世界是怎样的：

1. 为什么我项目部署了跑不起来？/ 这是什么问题？
   内心：我怎么知道呢？环境是什么、你部署了什么、出现了什么错误？

不要让别人对你的问题做阅读理解或者大家来找茬

2. 这里为什么报错？（几十行报错信息的截图）
   内心：我的妈呀这都是些啥？

请提供筛选或者过滤之后的错误信息

3. 这里为什么获取不到数据？
   内心：代码写得有问题呗。

粗心导致的问题常伴你左右

以上列举了3个高频的提问，当然这只是其中几个比较典型的。我们可以从这几个典型的提问中总结出两个共同的毛病：

• 自己不思考。

前面我们提到过，有问题要先利用搜索引擎，这其实也是思考的过程。绝大多数情况我们通过搜索引擎和仔细检查代码都能发现问题和解决问题，但是懒惰和不自信使得我们更倾向于直接向别人提问，因为这对于自己来说“更舒适”。

• 占用他人时间

坦白说，没有人有义务在网上花时间无偿为群众答疑解惑，你的每一个提问都意味着别人需要停下手中的事情来回答你的问题，哪怕大佬正在划水，那你也是打扰了大佬划水。正因为我们是在占用他人的时间，所以我们更应该谨慎的利用好每一次的提问的机会，在提问前先参考下第1点的内容，你的“舒适”很可能引起别人的“不舒适”。试想一下，你去医院看病，医生问你哪里不舒服，你说你猜。

• 总结和回顾

很多人习惯性在解决一个问题后就不会再去关注这个问题，就像一个没有感情的杀手。大佬写代码就不会遇到问题了吗？答案是否定的。大佬之所以看起来像免疫一切问题一样是因为当问题出现的时候，大佬总能高效的定位问题并解决问题。这里读者可能会说，因为他是大佬，我不是呀。这里我想说的是这个看法是错误的。诚然，我们要定位和解决问题是需要一定的技术功底支撑，但是这只是一部分，另一部分则是经验使然。无论是解决程序上的问题还是其他问题，我们都会有一些通用的解决流程作参考，比如先xxx，然后再xxx，但是当你有一定的行业经验之后，你是可以跳过某些环节直接达到xxx的目的，这就是经验的作用。而经验怎么来的呢？就是通过不断总结和回顾每一次解决问题的经历。

这里可以类比医院看病，现在一些医院医生开药，都是电脑输入XX病，然后系统就会返回一套方子，点击打印开药，这就是医学临床经验的结果。

回到我们的主题本身，作者观察发现，有些小伙伴一步一坑，一坑一提问，但是仔细观察会发现，这个问题和上一个问题其实解决的思路是一样的，都是可以用同样的手段定位问题，但是小伙伴浑然不知，这就是典型的没有总结和回顾，这种学习方式是很低效且容易打击自信心的。无论是解决问题也好，学习也好，思路、过程远比结果重要，问题的症状千变万化，但是原因终归那几样，一昧的追求“实现功能即可”只会让自己在舒适区中逐渐被淘汰，人生并没有太多“躺赢”的机会。

最后，推荐各位初学者抽空阅读一下经典名著《提问的智慧》。另外说明一点的就是，无论哪个行业，技术到了一定水准之后，必然会需要利用知识输出来提高自身、突破瓶颈，所以，大佬其实是很乐意回答问题的，只要你的提问是经过思考的。

为什么每个人的RESTful接口都不一样

RESTfull接口设计目前广泛应用于各种软件系统中，特别是前后端分离架构的web应用。相信各位web应用的开发者对这个概念并不陌生，但是我们经常会遇到几个这样的疑惑或者问题：

1. 为什么这个接口只设计了GET和POST两种请求类型？
2. 为什么这个接口无论是否请求成功，HTTP状态码永远只会是200?
3. 当一个查询的结果为空的时候，为什么有的接口设计会返回异常（HTTP状态码404或其他），有的则是会返回请求成功（HTTPS状态码200），但是返回结果是空数组或者null等表示结果为空的标识？

以上这几个问题，哪些是对的哪些是错的呢？答案是：没有对错。先不用惊讶，容我娓娓道来。

在我们试图搞清楚以上几个问题之前，首先需要读者了解或者阅读过关于RESTfull的定义，这类定义百度一搜一大把这里就不重复赘述了。接着是最好你实践过这类风格设计的接口，如果你心中也同样有这几个问题或者疑问那就更好了，当然最后这两点要求并不是必须。

如果你已经阅读过关于RESTfull的相关定义，你就会发现RESTfull是一种接口设计风格，它制定了一些原则条件，只要你遵守了，就算是RESTful风格的接口设计。那么问题就来了，这里面就存在很多灵活空间了，比如说我部分遵守，部分不遵守，可以吗？可以。或者说我在遵守的基础上，再自定义一些行为，可以吗？可以。各种诸如此类的实践路线导致了我们很难在开发生涯中真的看到有两个或更多的接口实现了一模一样的RESTfull风格接口，即便他们的业务是一样的。这是因为RESTfull本身既然是一种设计风格，那么风格发挥的主动权自然就是在开发者身上，而且绝大多数的项目所开发的API接口都是对内或者有限对外开放的，所以对于RESTfull的实践是否合格更多取决于内部团队老大的看法。

说到这里读者们可能会觉得，既然如此那这个真是太糟糕了，完全做不到统一，你完全想象不到别人设计出什么魔幻风格的RESTfull接口，为什么RESTfull依然能成为主流的接口设计风格呢？

这里我个人觉得有一部分原因是同行衬托，RESTfull基于HTTP协议,采用json格式的字符串作为传输内容，相对于过去的SOAP协议，采用XML格式标记语言来说，RESTfull无论从开发成本或者网络传输来说都显得轻量太多太多。而前面提到的，关于实际开发出来的RESTfull接口风格迥异的问题实际上并没有太糟糕，为什么这么说呢？因为最起码的一点是无论实际设计出来的接口再奇葩，总归是基于HTTP协议和使用JSON字符串来传递数据，这最起码保证了我们在调用别人设计好的接口的时候足够简单。当然，能调用跟实际交互还有一段很长的距离，而中间这个过程你是否舒适，有一部分就体现在接口细节设计上了。按照一般的经验，像这种”标准化“的设计，我们会封装一些基础方法来实现接口的调用和数据接收，但现实却是无法实现的。因为RESfull接口的具体实现细节上是因人而异的，这就导致了我们封装的调用或者解析代码未必能够完全复用，很典型的例子就是我们一开始抛出来的那几个问题。

这时候读者们肯定想说，还是想吐槽，是的，我们可以吐槽一个接口设计得很糟心，让我们调用起来很难受，但是我们又不可否认他确实遵守了RESTfull的基本规定，你可以发送一个HTTP请求,通过JSON来提交和接收数据，你完全拿对方没办法。所以这也就是为什么我们一开始给出的答案是：没有对错。我们可以吐槽一个接口设计得非常糟糕，但是不能说这个接口不是RESTfull接口，但是，我们可以评判一个接口是否严格遵循了RESTfull风格设计以及遵循的程度有多高。

我们可以从开局的几个问题入手来尝试评判下相应的接口设计是否很好的遵循了RESTfull风格设计。

1. 为什么这个接口只设计了GET和POST两种请求方法类型？

解析：HTTP协常用的请求方法类型有GET、POST、PUT、PATCH、DELETE、，其中毫无疑问GET和POST是最最最常用的，而且每个请求方法类型都有各自的描述：

序号	类型	描述
1	GET	请求指定的页面信息，并返回实体主体
2	POST	向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改
3	PUT	从客户端向服务器传送的数据取代指定的文档的内容
4	PATCH	是对 PUT 方法的补充，用来对已知资源进行局部更新
5	DELETE	请求服务器删除指定的页面

从上面的表格可以看出，不同类型的请求方法有着自己明确的含义，在理想的情况下，我们可以通过一个请求类型+请求地址的形式，直观的看出一个接口的作用，比如：

// 猜猜我想干嘛
GET https://xxxx.com/users

DELETE  https://xxxx.com/uid/69

这里读者可以尝试做一个阅读理解。
那么这里问题就来了，既然HTTP的请求方法类型有助于我们理解一个接口的作用，为什么在有些接口中唯独只会使用GET和POST呢？这里面我觉得原因有很多，有些可能我也想不到也猜不到，但是我从个人开发经验上尝试猜测一下。

原因我觉得可能是一是懒，二是觉得没必要。坦白说，除了查询请求这种无可争议的使用GET之外，其他的全部归为POST无疑是一件很方便的事。你不需要花时间去考虑接口的行为然后决定要定义成什么请求方法类型，反正具体的实现逻辑都是一样的，而且POST方法的描述也似乎能涵盖到其他几个类型的请求方法。但这里读者可能会说，在某些场景下会有歧义，比如说我们要调用一个接口实现删除一个用户：

  // 猜猜我想干嘛
  POST https://xxxx.com/uid/69

这里我们复用了前面其中一道阅读理解题并把类型改成了POST。这里第一眼看上去确实不能很好的表达接口的意图，但是我们有接口文档呀，我在相应的接口名称中写清楚再放大字体说这个接口是删除用户用的不就完事了？这么一听好像也有道理。所以综合看来，细分各个方法请求类型似乎变成一件很多余的事，吃力不讨好，干脆就GET/POST一把梭了。

说到这里，我们再回过头来看看问题本身，做错了吗？没有。那严格遵循了RESTfull风格设计了吗，那倒是并没有。RESTfull是基于HTTP协议的，HTTP协议里面清清楚楚明明白白提供了这些方法类型，那么从严谨的角度上来说，我们确实是需要清楚的定义好每个请求的类型是什么。这不仅是有利于提高接口语义化，其实对接口地址定义也有些好处，比如说我们要定义一套对用户进行CRUD的接口：

  // 遵循RESTfull
  GET     https://xxxx.com/users

  GET     https://xxxx.com/user/1

  POST    https://xxxx.com/user
  Body:   "{"username":"qinchen","password":123446}"

  PUT     https://xxxx.com/user/1
  Body:   "{"username":"qinchen1","password":999999}"

  PATCH   https://xxxx.com/user/69
  Body:   "{"password":999999}"

  DELETE  https://xxxx.com/user/1

  // 不遵循RESTfull
  GET     https://xxxx.com/users

  GET     https://xxxx.com/user/1

  POST    https://xxxx.com/user
  Body:   "{"username":"qinchen","password":123446}"

  POST    https://xxxx.com/put/user/1
  Body:   "{"username":"qinchen1","password":999999}"

  POST    https://xxxx.com/patch/user/69
  Body:   "{"password":999999}"

  POST    https://xxxx.com/delete/user/1

注意：在不遵循RESTfull风格的情况下，因为除了GET以外都是POST类型请求，我们需要为相同POST请求的接口定义不同的路由地址，这里示例中的路由地址只是为了体现这一点，真实开发场景中如何命名各有各发挥。

从这里的示例可以看出，在不遵循RESTfull风格设计的情况下我们难免需要在接口URL地址中增加一些描述性的单词，这会导致路由接口地址变得很冗长和不够优雅，当然如果你觉得这不是什么问题那也是没错的，对，你没错。

最后总结一下这个问题就是，你可以不遵循RESTfull风格设计里面关于对请求方法类型的区分定义，但需要在路由地址上花心思，那么在真实开发场景中，我们该如何选择呢？我的建议是如果你能做主，而且觉得有必要，就严格遵循，反之，领导说就啥吧。

2. 为什么这个接口无论是否请求成功，HTTP状态码永远只会是200?

解析：常见的HTTP状态码有如下几种：

状态码	状态码英文名称	描述
200	OK	请求成功。一般用于GET与POST请求
201	Created	已创建。成功请求并创建了新的资源
301	Moved Permanently	永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302	Found	临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
304	Not Modified	未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
400	Bad Request	客户端请求的语法错误，服务器无法理解
401	Unauthorized	请求要求用户的身份认证
402	Payment Required	保留，将来使用
403	Forbidden	服务器理解请求客户端的请求，但是拒绝执行此请求
404	Not Found	服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
500	Internal Server Error	服务器内部错误，无法完成请求

从上面表格可以看出，HTTP码是用于标识本次请求响应的结果状态,通过HTTP状态我们可以直观的判断出本请求是不是成功的，但是为什么有些接口设计的情况是无论成功与否都只会返回200的状态码呢？

这里的原因和第1点的问题大致相同，就是懒和觉得没必要。但相对于明确方法请求类型来说，明确接口响应的HTTP状态码却是大有意义。

首先假设我们把所有请求响应的HTTP状态码都标识为200，那么我们必然需要在响应内容中增加一些字段来描述本次错误，例如：

// 200
{
  // 定义一个错误码
  "code": 1024,
  // 错误码对应的错误信息描述
  "message": "密码不正确"
}

这里大家可能会觉得，我们已经有code和message字段来描述本次请求的错误了，完全不需要HTTP状态码。这里乍一看是没有问题的，前端也能在统一异常处理的层面很好的捕获异常。但是，当你的系统到了一定的规模（这个很容易达到，并不要求需要多大的规模体量，只要不是demo项目），你的错误类型就会有很多种，往往我们的错误码清单会很长，当然这对于后端开发来说不是啥问题，因为这个信息其实是给前端开发者处理的，但是前端开发者在处理这些错误的时候就难受了。

难受在哪？假设我们现在有10个关于账户异常的错误码，10个关于业务A的错误码，10个关于业务B的错误码，一共30个。这里面有个业务需求，就是某些特定的错误码需要前端做出特定的行为，比如说跳转到指定页面，或者强制退出啥等等。那么这时候前端在统一异常处理的时候咋做？那就是各种if/else和switch判断。看起来似乎也问题不大嘛，是的，接着我们需求变了，和原来不一样了，原来的分支判断条件可能不适用了，错误码改了，含义不一样了，或者又增加了30个新的错误码，那么这时候前端开发者就炸了。所以从这里可以看出，单纯依靠错误码来实现前端统一异常处理依然会存在重复编码问题，那么如果我们严格遵循RESTfull风格设计的话，增加HTTP状态码的区分定义，同时保留原来的错误响应信息结果会是如何？这时候前端开发者在做统一异常处理的时候，先按状态码做一层大范围的分支处理，再有针对性的对这个状态码类型下的某些错误码做特殊处理即可。这两种方式的区别在于，通过HTTP状态码相当于给错误码做了一个归类，这也符合真实开发场景的异常处理情况。多数情况下前端在对异常做统一处理的时候，同一类型的异常往往后续的处理行为是一致的。

比如说给后端传递了错误的参数，这种一般后端在校验不通过的时候，会返回的HTTP状态码是400。这类提示信息是需要把具体错误信息展示给用户作为警告提示的，那么前端开发者在统一异常处理的时候，只需要判断HTTP状态码是不是400，是的话直接把具体内容以各种弹出提示的形式展示即可，不用关心具体的错误码又是什么（需要特殊处理的除外）。还有一种是401和403 HTTP状态码的错误，这两种都是跟权限有关的错误，前端开发者在做统一异常处理的时候也可以进行针对性的统一捕获处理。

从上面举的一些例子可以看出，相同的HTTP状态码，前端的处理行为往往是一致的，但错误码未必。相对于单纯依靠错误码，HTTP状态码+错误码的方式让前端开发者更容易实现封装和统一处理，前端开发者根据HTTP状态码定义不同的响应处理，可以大大减少开发工程量和降低沟通成本。但是这里读者们可能会说，我们可以把错误码按范围划分，实现比如1~99是代表XX类型错误，100~199是XX类型错误。这个确实可以，但是这等于是换了条路开倒车，其实还是会有一开始的提到的痛点问题出现。而且错误码因为是团队定义的，如果维护不善会导致各种前后端开发者信息不同步的问题，既然通过HTTP状态码的定义就能解决大部分问题了为什么不用呢？

最后总结一下这个问题就是，强烈建议严格按照HTTP状态码的定义区分接口响应的HTTP状态码，错误码作为一种细分的补充。

3. 当一个查询的结果为空的时候，为什么有的接口设计会返回异常（HTTP状态码404或其他），有的则是会返回请求成功（HTTPS状态码200），但是返回结果是空数组或者null等表示结果为空的标识？

解析：这个问题情况有点特殊，理论上来说，当我们查询了资源然后结果是不存在的时候，这个时候用404的HTTP状态码来标识本次请求的响应状态是一点问题都没有的，也是非常规范的做法。但是这是建立在业务场景规定，查询结果为空的时候属于异常的前提上。这句话非常重要！当我们查询一个资源但是结果为空，到底要不要把本次请求视为一个404的异常是取决于业务场景。如果说业务场景认为”空“是允许的，那么就不应该让本次响应是一个404的HTTP状态码，因为有些业务场景下，“空”也是有它的业务含义的，比如我们要查询一个月内连续登陆10天的用户列表，结果是没有用户满足这个条件，那么我返回的结果自然是空的，并不能视为一个异常，这时候返回一个200的HTTP状态码，然后在响应结果里面明确结果是空的才是正确的做法。那么什么场景下”空“是不允许的呢？比如说我们要修改指定的某个用户的个人信息，那么通常情况下我们后端的处理逻辑是这样的：查询这个用户是否存在，如果存在则进行更新操作，如果不存在，抛出一个异常提示要修改的用户不存在。在这种场景下，这个异常就会是一个404异常，我们尝试修改一个并不存在的用户。

最后总结一下这个问题，当请求的结果为空时，是不是属于异常要考虑业务场景，并且这个划分定义也是很有必要的，可以避免潜在的业务理解偏差导致的程序执行逻辑问题，因为如果是一个异常，那么会更早的被前端在统一异常处理里面的捕获并处理，有利于前、后端开发人员开发出更健壮的系统。

以上就是我要和大家分享的关于在实践RESTfull过程中的一些见解分享，如果你还有一些对于RESTfull风格设计有什么困惑的地方也可以留言评论大家一起讨论。