简单API Server框架

按照前面几章的写法，先来看看加法、减法示例代码：

代码写多了一眼就可以看出来，这么简单的加减乘除，居然写了这么长，而且还要对每个 API 都写一个 location ，作为有追求的人士，怎能容忍这种代码风格？

首先是需要把这些 location 合并；
其次是这些接口的实现放到独立文件中，保持 Nginx 配置文件的简洁；

基于这两点要求，可以改成下面的版本，看上去有那么几分模样了：


error_log logs/error.log;   #指定错误日志文件路径
events {
    worker_connections 1024;
}
http {
    # 设置默认 lua 搜索路径，添加 lua 路径
    # 此处写相对路径时，对启动 Nginx 的路径有要求，必须在 Nginx 目录下启动，require 找不到
    # comm.param 绝对路径当然也没问题，但是不可移植，因此应使用变量 $prefix 或
    # ${prefix}，OR 会替换为 Nginx 的 prefix path。
    # lua_package_path 'lua/?.lua;/blah/?.lua;;';
    lua_package_path '$prefix/lua/?.lua;/blah/?.lua;;';
    # 这里设置为 off，是为了避免每次修改之后都要重新 reload 的麻烦。
    # 在生产环境上务必确保 lua_code_cache 设置成 on。
    lua_code_cache off;
        # 在代码路径中使用 Nginx 变量
        # 注意：使用 Nginx var 的变量一定要谨慎，否则将会带来非常大的风险
        location ~ ^/api/([-_a-zA-Z0-9/]+) {
            # 准入阶段完成参数验证
            access_by_lua_file  lua/access_check.lua;
            # 内容生成阶段
            content_by_lua_file lua/$1.lua;
        }
    }
}

既然对外提供的是 API Server，作为一个服务端程序员，怎么可以容忍输入参数不检查呢？万一对方送过来的不是数字或者为空，这些都要过滤掉嘛。参数检查过滤的方法是统一，在这几个 API 中如何共享这个方法呢？这时候就需要 Lua 模块来完成了。

使用统一的公共模块，完成参数验证；
验证入口最好也统一，不要分散在不同地方；

worker_processes  1;        # Nginx worker 数量
error_log logs/error.log;   # 指定错误日志文件路径
events {
    worker_connections 1024;
}
http {
        # 在代码路径中使用 Nginx 变量
        # 注意：使用 Nginx var 的变量一定要谨慎，否则将会带来非常大的风险
        location ~ ^/api/([-_a-zA-Z0-9/]+) {
            access_by_lua_file  lua/access_check.lua;
            content_by_lua_file lua/$1.lua;
        }
    }
}

看看 curl 测试结果吧：

$ curl '127.0.0.1:80/api/addition?a=1'
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>openresty/1.9.3.1</center>
</body>
</html>
$ curl '127.0.0.1:80/api/addition?a=1&b=3'

基本是按照预期执行的。参数不全、错误时，会提示 400 错误。正常处理，可以返回预期结果。

来整体看一下目前的目录结构：

本章目的是搭建一个简单 API Server，记住这绝对不是终极版本。这里面还有很多需要进一步去考虑的地方，但是作为最基本的框架已经有了。

简单 API Server 框架

简单API Server框架