把业务逻辑直接变成Web服务，DB2实操体验分享

直接提供“把业务逻辑直接变成Web服务，DB2实操体验分享”的内容如下：

前段时间,我参与了一个挺有意思的项目，里面用到了IBM DB2数据库的一个功能，叫“Native REST API”，翻译过来大概就是“原生的REST接口”，这个功能的核心思想，就像标题说的，“把业务逻辑直接变成Web服务”，啥意思呢？就是说，我们不用像传统方式那样，先写SQL，再写Java或Python代码，然后架设一个Spring Boot或者Flask这样的Web应用服务器，最后把API暴露出去，相反，我们可以直接在DB2数据库里，通过写一些特定的SQL脚本（他们管这个叫“模块”Module），然后通过一条简单的命令，DB2自己就能生成一个标准的HTTP REST API接口，前端应用或者别的系统，就能像调用普通网址一样，直接来访问这个接口，从而执行数据库里的操作。

（来源：技术分享会的开场介绍和问题背景阐述）

一开始听到这个,我的感觉是既好奇又有点怀疑，好奇是因为这听起来确实能省好多事，怀疑是觉得数据库直接暴露API，会不会不安全？性能怎么样？会不会很麻烦？带着这些疑问，我开始动手尝试。

我们的DB2数据库版本是挺新的,支持这个功能，第一步，我们需要在数据库里创建一个所谓的“模块”，这个模块，其实就是一个容器，里面放着我们想要暴露成API的那些“业务逻辑”，这个业务逻辑，就是用SQL写的一个个函数或者存储过程，我们有个需求是让前端能根据员工ID查询他的部门信息，传统做法是，我在后端代码里写个DAO，写条SELECT的SQL语句，现在呢，我们直接在DB2里创建一个函数，比如叫GET_EMPLOYEE_DEPT，这个函数接收一个员工ID参数，返回部门信息。

（来源：实操演示中创建模块和函数的步骤）

创建好函数之后,重头戏来了，我们不需要写一行Web服务的代码，只需要执行一条DB2的命令，大概是CALL SYSPROC.REGISTER_REST_SERVICE这样的，这条命令会告诉DB2：“嘿，请把我刚才创建的那个GET_EMPLOYEE_DEPT函数，变成一个REST API。” 执行完之后，DB2会返回给我们一个URL，比如是 https://我们的数据库服务器地址:端口号/dbapi/v1/模块名/GET_EMPLOYEE_DEPT，这个URL就是一个活生生的、可以用的API接口了！

（来源：演示注册REST服务并获取URL的过程）

拿到这个URL,我半信半疑地用Postman（一个测试API的工具）试了一下，按照规则，对于这种查询类的GET请求，参数需要通过URL路径传递，我在URL后面加上了具体的员工ID，.../GET_EMPLOYEE_DEPT/1001，然后点发送，神奇的事情发生了，页面上真的返回了JSON格式的数据，正是ID为1001的员工所在部门的信息！整个过程，我没有写任何关于HTTP、JSON转换或者路由的代码，全是DB2自动完成的，这种感觉确实很直接。

（来源：分享者现场用Postman测试生成的API）

不只是查询,增删改（POST， PUT， DELETE）也可以，比如要新增一个员工，我们可以在模块里创建一个存储过程，这个过程接受姓名、部门号等参数，然后执行INSERT操作，注册服务时，指定这个方法对应HTTP的POST请求，调用的时候，用POST方法访问那个URL，并把数据放在请求的JSON body里，DB2会自动解析JSON，把参数传给存储过程去执行。

（来源：后续演示创建和测试增删改API的例子）

体验下来,优点很明显： 第一，开发速度飞快，对于简单的CRUD（增删改查）操作，简直是秒出API，大大减少了后端开发的工作量。 第二，维护点集中，因为业务逻辑（SQL）就在数据库里，API也是数据库生成的，所以不需要在应用服务器和数据库之间来回折腾，改个SQL逻辑，API自然就变了。

也遇到了一些需要琢磨的地方和挑战： 首先就是安全问题，数据库直接暴露API，听着就让人担心，DB2也提供了安全机制，比如可以通过配置要求API调用者提供用户名密码进行HTTP Basic认证，或者集成更高级的认证方式，但这需要DBA（数据库管理员）和安全工程师仔细规划和配置，不能掉以轻心。 其次是灵活性问题，这种自动生成的API，格式是DB2定好的，如果前端需要一个特别复杂的、需要联表查询再加点计算才能返回的数据结构，用SQL函数或存储过程写起来可能就很冗长、不好维护，不如在Java等编程语言里处理起来那么自如，它更适合相对标准、简单的数据交互场景。 还有就是性能考量，虽然省去了中间应用服务器，所有计算都在数据库内部完成，理论上延迟可能更低，但如果并发请求很高，所有的压力就直接给到了数据库本身，对数据库的性能和资源调配要求就更高了。

（来源：分享会后续的优缺点讨论和答疑环节）

这次DB2的实操体验让我觉得,“把业务逻辑直接变成Web服务”这个想法在特定场景下是非常有吸引力的工具，它有点像数据库给我们提供了一个“一键发布”Web API的超能力，对于需要快速构建原型、或者做微服务架构中一些简单的数据服务的场景，它能极大地提升效率，但它也不是万能的，尤其是在处理复杂业务逻辑、高安全性要求和非常灵活的接口需求时，可能还是需要传统的应用服务器层来把关，关键是要根据项目的具体需求，判断什么时候该用这把“瑞士军刀”，什么时候还是需要上“全套工具”，这次体验让我对数据库的能力边界有了新的认识。

（来源：分享者的总结与感悟部分）