看看人家接口写得，那叫一个优雅！-低调大师

看看人家接口写得，那叫一个优雅！

2020-12-05 501

点击上方 java项目开发，选择设为星标

优质文章，及时送达

--

来源：https://zhuanlan.zhihu.com/p/265318078

在移动互联网，分布式、微服务盛行的今天，现在项目绝大部分都采用的微服务框架，前后端分离方式，（题外话：前后端的工作职责越来越明确，现在的前端都称之为大前端，技术栈以及生态圈都已经非常成熟；以前后端人员瞧不起前端人员，那现在后端人员要重新认识一下前端，前端已经很成体系了）。

一般系统的大致整体架构图如下：

需要说明的是，有些小伙伴会回复说，这个架构太简单了吧，太low了，什么网关啊，缓存啊，消息中间件啊，都没有。因为老顾这篇主要介绍的是API接口，所以我们聚焦点，其他的模块小伙伴们自行去补充。

接口交互

前端和后端进行交互，前端按照约定请求URL路径，并传入相关参数，后端服务器接收请求，进行业务处理，返回数据给前端。

针对URL路径的restful风格，以及传入参数的公共请求头的要求（如：app_version,api_version,device等），老顾这里就不介绍了，小伙伴们可以自行去了解，也比较简单。

着重介绍一下后端服务器如何实现把数据返回给前端？

返回格式

后端返回给前端我们一般用JSON体方式，定义如下：

  
  
  
   
   {
	#返回状态码
	code:integer,		
	#返回信息描述
	message:string,
	#返回值
	data:object
}

CODE状态码

code返回状态码，一般小伙伴们是在开发的时候需要什么，就添加什么。

如接口要返回用户权限异常，我们加一个状态码为101吧，下一次又要加一个数据参数异常，就加一个102的状态码。这样虽然能够照常满足业务，但状态码太凌乱了

我们应该可以参考HTTP请求返回的状态码

  
  
  
   
   下面是常见的HTTP状态码：
200 - 请求成功
301 - 资源（网页等）被永久转移到其它URL
404 - 请求的资源（网页等）不存在
500 - 内部服务器错误

我们可以参考这样的设计，这样的好处就把错误类型归类到某个区间内，如果区间不够，可以设计成4位数。

  
  
  
   
   #1000～1999 区间表示参数错误
#2000～2999 区间表示用户错误
#3000～3999 区间表示接口异常

这样前端开发人员在得到返回值后，根据状态码就可以知道，大概什么错误，再根据message相关的信息描述，可以快速定位。

Message

这个字段相对理解比较简单，就是发生错误时，如何友好的进行提示。一般的设计是和code状态码一起设计，如：

再在枚举中定义，状态码

状态码和信息就会一一对应，比较好维护。

Data

返回数据体，JSON格式，根据不同的业务又不同的JSON体。

我们要设计一个返回体类Result

控制层Controller

我们会在controller层处理业务请求，并返回给前端，以order订单为例

我们看到在获得order对象之后，我们是用的Result构造方法进行包装赋值，然后进行返回。小伙伴们有没有发现，构造方法这样的包装是不是很麻烦，我们可以优化一下。

美观优化

我们可以在Result类中，加入静态方法，一看就懂

那我们来改造一下Controller

代码是不是比较简洁了，也美观了。

优雅优化

上面我们看到在Result类中增加了静态方法，使得业务处理代码简洁了。但小伙伴们有没有发现这样有几个问题：

1、每个方法的返回都是Result封装对象，没有业务含义
2、在业务代码中，成功的时候我们调用Result.success，异常错误调用Result.failure。是不是很多余
3、上面的代码，判断id是否为null，其实我们可以使用hibernate validate做校验，没有必要在方法体中做判断。

我们最好的方式直接返回真实业务对象，最好不要改变之前的业务方式，如下图

这个和我们平时的代码是一样的，非常直观，直接返回order对象，这样是不是很完美。那实现方案是什么呢？

实现方案

小伙伴们怎么去实现是不是有点思路，在这个过程中，我们需要做几个事情

1、定义一个注解@ResponseResult，表示这个接口返回的值需要包装一下
2、拦截请求，判断此请求是否需要被@ResponseResult注解
3、核心步骤就是实现接口ResponseBodyAdvice和@ControllerAdvice，判断是否需要包装返回值，如果需要，就把Controller接口的返回值进行重写。

注解类

用来标记方法的返回值，是否需要包装

拦截器

拦截请求，是否此请求返回的值需要包装，其实就是运行的时候，解析@ResponseResult注解

此代码核心思想，就是获取此请求，是否需要返回值包装，设置一个属性标记。

重写返回体

上面代码就是判断是否需要返回值包装，如果需要就直接包装。这里我们只处理了正常成功的包装，如果方法体报异常怎么办？处理异常也比较简单，只要判断body是否为异常类。

怎么做全局的异常处理，篇幅原因，老顾这里就不做介绍了，只要思路理清楚了，自行改造就行。

重写Controller

在控制器类上或者方法体上加上@ResponseResult注解，这样就ok了，简单吧。到此返回的设计思路完成，是不是又简洁，又优雅。

总结

这个方案还有没有别的优化空间，当然是有的。如：每次请求都要反射一下，获取请求的方法是否需要包装，其实可以做个缓存，不需要每次都需要解析。当然整体思路了解，小伙伴们就可以在此基础上面自行扩展。谢谢！！！

- END -

温暖提示

为了方便大家更好的学习，本公众号经常分享一些完整的单个功能案例代码给大家去练习，如果本公众号没有你要学习的功能案例，你可以联系小编（微信：xxf960513）提供你的小需求给我，我安排我们这边的开发团队免费帮你完成你的案例。

注意：只能提单个功能的需求不能要求功能太多，比如要求用什么技术，有几个页面，页面要求怎么样？

请长按识别二维码

想学习更多的java功能案例请关注

Java项目开发

如果你觉得这个案例以及我们的分享思路不错，对你有帮助，请分享给身边更多需要学习的朋友。别忘了《留言+点在看》给作者一个鼓励哦！

本文分享自微信公众号 - web项目开发（javawebkaifa）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

微信关注我们

原文链接：https://my.oschina.net/u/4606165/blog/4776825

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

翻译 | 《JavaScript Everywhere》第18章带Electron的桌面应用程序

翻译 | 《JavaScript Everywhere》第18章带Electron的桌面应用程序写在最前面大家好呀，我是毛小悠，是一位前端开发工程师。正在翻译一本英文技术书籍。为了提高大家的阅读体验，对语句的结构和内容略有调整。如果发现本文中有存在瑕疵的地方，或者你有任何意见或者建议，可以在评论区留言，或者加我的微信：code\_maomao，欢迎相互沟通交流学习。 (σﾟ∀ﾟ)σ..:*☆哎哟不错哦第18章带Electron的桌面应用程序我第一次接触个人计算机是在一个充满Apple II机器的学校实验室中进行的。每周一次，我和我的同学被老师带进教室，给了一些软盘，并给出了有关如何加载应用程序（通常是Oregon Trail）的粗略说明。在这些课程上，除了记得自己发呆之外，我对其他事情记不清了。自1980年代中期以来，个人计算机已经走了很长一段路，但是我们仍然需要依靠桌面应用程序来执行许多任务。通常，我可能会访问电子邮件客户端、文本编辑器、聊天客户端、电子表格软件、音乐流服务以及其他多个桌面应用程序。一般，这些应用程序具有与Web应用程序等效的功能，但是桌面应用程序的...

2020-12-06

524

本文转自知乎，作者mileistone，已获作者授权转载，请勿二次转载。 https://zhuanlan.zhihu.com/p/330613654 目标检测模型训练的时候有两个任务，框分类（框里是什么）和框回归（框在哪），本文主要讲第二点。框回归可以分为两大类，基于x，y，w，h的回归（比如Faster R-CNN、YOLO、RetinaNet里框回归的loss），基于IoU的回归（比如IoU loss、GIoU loss、DIoU loss、CIoU loss）。基于x，y，w，h的回归基于x，y，w，h的回归，可以细分为x、y（GT框的中心）的回归和w、h的回归。 w、h的回归 Faster R-CNN、YOLO、RetinaNet的w、h回归方式大体相同。假设、为拟合目标，、为网络预测值，为GT框的宽，为样本对应anchor框的宽，为GT框的宽，为GT框对应的anchor框的高，为、、等。其中通过anchor的归一化和取log，可以一定程度增加和对框scale的invariance。 x、y的回归 x、y的回归方式可以分为两类，一类以YOLO为代表，一类以Faster...

2020-12-05

581

资源下载

更多资源

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。