GoZero Api 服务

GoZero框架可以作为一个单体服务的开发框架。与大多数基于proto或者thrift定义的接口描述文件生成基本代码的框架（包括GoZero可以通过proto生成代码）类似，GoZero为RESTAPI也提供了这种生成服务。

它需要一个所谓的API文件，为了方便我们的使用，他有在VSCode和Intelij上提供名为Goctl的插件用于实现辅助操作和代码高亮。这种API文件格式类似于Go语言的语法，具体示例就不给出了。其中可以定义API交互的数据结构，路由端点endpoint（支持path参数），请求方法。

基于这些定义，使用官方提供的工具，可以生成一般意义上的处理器层（有生成的逻辑）和业务逻辑层（空逻辑），类型定义，以及入口文件，默认的配置文件。

GoZero在设计上把业务逻辑层设计成如下的形式:

// 代码有省略，仅示意
Alogic struct{}

func(...) xxxxxlogic(context,req) resp{}

业务逻辑层仅仅和请求数据和返回的数据，这样和处理器层降低了耦合程度，这是好处，业务逻辑就专心处理业务逻辑，根据请求的那些参数生成一个相应对象，保持简单的职责。但是这也意味着不能够直接影响相应的HTTP请求对象和相应对象，这会给某些场景带来一些不便，暂且不表。

处理器层只需要把数据转换成json数据就行，并且保证类型安全。这其实是个很强的假设，HTTP给请求提供了太多的东西，有很强的灵活性，而这里的REST API把参数限制了，姑且也能算作是KISS的体现吧。处理器层算是GoZero提供的路由框架，因此也提供了中间件接口，可以做一些hook处理。

类型纯粹是一些定义，配置则是基于yaml，相对还算友好。

再来扒一扒它的缺点，为了让每次都能拿到共享一些数据对象，使用了一个自定义的Context上下文对象，并且每层都依赖他，耦合稍微有点重。 除此之外，作为作为API服务，文件传输是必备的，GoZero在上传文件这里并不是很友好，同样的还有用它实现websocket功能也不友好。因为它限制了数据结构。官方给的websocket实现，就是把逻辑层和处理器层魔改，传给它请求和响应流对象。同理上传/下载文件官方给的示例也是魔改两层，用原本的响应或者请求流对象作为传入/传出参数。这两种情况最大的问题在于他要魔改生成的代码，而生成的代码有时候需要改动重新生成会覆盖掉魔改部分。

总而言之，对于大部分情况来说，可以让人省掉很多的事情。而对于少部分的情况，需要做一点魔改，但是这少部分情况毕竟也确实不太一样，可以理解。