location 的设计

whs860603 · 2015-09-07T13:48:54+00:00

Hello! 2015-09-07 10:36 GMT+08:00 X山鹰: > 直接使用proxy_pass进行代理, 在不&#x4F7...

location 的设计

whs860603

location 的设计

我现在有一组http api接口，如下所示

只有/[type]/id，则为读取某个资源最新版本的操作

形如/[type]/id/_history/vid，则为读取某个资源具体某个版本的操作

存在/[type]/?，则为查询操作，根据?后面的键值对形式的参数来处理

形如/[type]/id/_history/，则为读取某个资源所有版本的操作

形如/[type]/_history/，则为读取所有同类型资源所有版本的操作

其中[type] 可以是Patient、Provider、Organization(可以更多)

id和vid都是string [A-Za-z0-9\-\.]{1,64}

这时候我是

1、定义一个/ 然后在里面根据拿到的uri参数的具体情况来分别处理

location / {

}

2、定义多个 location，通过编写匹配规则来精确定位每一个api

但url里又有不止一个可变动的地方，不知有没有可以参考的正则写法

eagle-china

直接使用nodejs的express框架写http api哇

然后用nginx代理过去这样会比在nginx里面写会更好的

Date: Sun, 6 Sep 2015 22:48:54 -0700
From: whs8...@gmail.com
To: openresty@googlegroups.com
Subject: [openresty] location 的设计

location 的设计

我现在有一组http api接口，如下所示

只有/[type]/id，则为读取某个资源最新版本的操作

形如/[type]/id/_history/vid，则为读取某个资源具体某个版本的操作

存在/[type]/?，则为查询操作，根据?后面的键值对形式的参数来处理

形如/[type]/id/_history/，则为读取某个资源所有版本的操作

形如/[type]/_history/，则为读取所有同类型资源所有版本的操作

其中[type] 可以是Patient、Provider、Organization(可以更多)

id和vid都是string [A-Za-z0-9\-\.]{1,64}

这时候我是

1、定义一个/ 然后在里面根据拿到的uri参数的具体情况来分别处理

location / {

}

2、定义多个 location，通过编写匹配规则来精确定位每一个api

但url里又有不止一个可变动的地方，不知有没有可以参考的正则写法

whs860603

能给个例子的链接么我是打算直接用postgrest做后端它本身就能抛http api 然后套上openresty就好了

在 2015年9月7日星期一 UTC+8下午4:00:37，X山鹰写道：

直接使用nodejs的express框架写http api哇
然后用nginx代理过去这样会比在nginx里面写会更好的

Date: Sun, 6 Sep 2015 22:48:54 -0700
From: whs8...@gmail.com
To: open...@googlegroups.com
Subject: [openresty] location 的设计

location 的设计

我现在有一组http api接口，如下所示

只有/[type]/id，则为读取某个资源最新版本的操作
形如/[type]/id/_history/vid，则为读取某个资源具体某个版本的操作
存在/[type]/?，则为查询操作，根据?后面的键值对形式的参数来处理
形如/[type]/id/_history/，则为读取某个资源所有版本的操作
形如/[type]/_history/，则为读取所有同类型资源所有版本的操作

其中[type] 可以是Patient、Provider、Organization(可以更多)
id和vid都是string [A-Za-z0-9\-\.]{1,64}

这时候我是
1、定义一个/ 然后在里面根据拿到的uri参数的具体情况来分别处理

location / {
}
2、定义多个 location，通过编写匹配规则来精确定位每一个api
但url里又有不止一个可变动的地方，不知有没有可以参考的正则写法

--

eagle-china

你可以再后端跑个nodejs的服务前面套个nginx或者openresty一样可以实现
http://expressjs.com/4x/api.html#app.param

这个是路由定义你可以看看

希望对你有帮助

Date: Mon, 7 Sep 2015 02:13:21 -0700
From: whs8...@gmail.com
To: openresty@googlegroups.com
CC: eagle...@hotmail.com
Subject: Re: [openresty] location 的设计

能给个例子的链接么我是打算直接用postgrest做后端它本身就能抛http api 然后套上openresty就好了

在 2015年9月7日星期一 UTC+8下午4:00:37，X山鹰写道：

直接使用nodejs的express框架写http api哇
然后用nginx代理过去这样会比在nginx里面写会更好的

Date: Sun, 6 Sep 2015 22:48:54 -0700
From: whs8...@gmail.com
To: open...@googlegroups.com
Subject: [openresty] location 的设计

location 的设计

我现在有一组http api接口，如下所示

只有/[type]/id，则为读取某个资源最新版本的操作
形如/[type]/id/_history/vid，则为读取某个资源具体某个版本的操作
存在/[type]/?，则为查询操作，根据?后面的键值对形式的参数来处理
形如/[type]/id/_history/，则为读取某个资源所有版本的操作
形如/[type]/_history/，则为读取所有同类型资源所有版本的操作

其中[type] 可以是Patient、Provider、Organization(可以更多)
id和vid都是string [A-Za-z0-9\-\.]{1,64}

这时候我是
1、定义一个/ 然后在里面根据拿到的uri参数的具体情况来分别处理

location / {
}
2、定义多个 location，通过编写匹配规则来精确定位每一个api
但url里又有不止一个可变动的地方，不知有没有可以参考的正则写法

--

eagle-china

你可以再后端跑个nodejs的服务前面套个nginx或者openresty一样可以实现
http://expressjs.com/4x/api.html#app.param

这个是路由定义你可以看看

希望对你有帮助

Date: Mon, 7 Sep 2015 02:13:21 -0700
From: whs8...@gmail.com
To: openresty@googlegroups.com
CC: eagle...@hotmail.com
Subject: Re: [openresty] location 的设计

能给个例子的链接么我是打算直接用postgrest做后端它本身就能抛http api 然后套上openresty就好了

在 2015年9月7日星期一 UTC+8下午4:00:37，X山鹰写道：

直接使用nodejs的express框架写http api哇
然后用nginx代理过去这样会比在nginx里面写会更好的

Date: Sun, 6 Sep 2015 22:48:54 -0700
From: whs8...@gmail.com
To: open...@googlegroups.com
Subject: [openresty] location 的设计

location 的设计

我现在有一组http api接口，如下所示

只有/[type]/id，则为读取某个资源最新版本的操作
形如/[type]/id/_history/vid，则为读取某个资源具体某个版本的操作
存在/[type]/?，则为查询操作，根据?后面的键值对形式的参数来处理
形如/[type]/id/_history/，则为读取某个资源所有版本的操作
形如/[type]/_history/，则为读取所有同类型资源所有版本的操作

其中[type] 可以是Patient、Provider、Organization(可以更多)
id和vid都是string [A-Za-z0-9\-\.]{1,64}

这时候我是
1、定义一个/ 然后在里面根据拿到的uri参数的具体情况来分别处理

location / {
}
2、定义多个 location，通过编写匹配规则来精确定位每一个api
但url里又有不止一个可变动的地方，不知有没有可以参考的正则写法

--

whs860603

我后台有一套java的不过还是谢谢

在 2015年9月7日星期一 UTC+8下午5:44:37，X山鹰写道：

你可以再后端跑个nodejs的服务前面套个nginx或者openresty一样可以实现
http://expressjs.com/4x/api.html#app.param
这个是路由定义你可以看看
希望对你有帮助

Date: Mon, 7 Sep 2015 02:13:21 -0700
From: whs8...@gmail.com
To: open...@googlegroups.com
CC: eagle...@hotmail.com
Subject: Re: [openresty] location 的设计

能给个例子的链接么我是打算直接用postgrest做后端它本身就能抛http api 然后套上openresty就好了

在 2015年9月7日星期一 UTC+8下午4:00:37，X山鹰写道：

直接使用nodejs的express框架写http api哇
然后用nginx代理过去这样会比在nginx里面写会更好的

Date: Sun, 6 Sep 2015 22:48:54 -0700
From: whs8...@gmail.com
To: open...@googlegroups.com
Subject: [openresty] location 的设计

location 的设计

我现在有一组http api接口，如下所示

只有/[type]/id，则为读取某个资源最新版本的操作
形如/[type]/id/_history/vid，则为读取某个资源具体某个版本的操作
存在/[type]/?，则为查询操作，根据?后面的键值对形式的参数来处理
形如/[type]/id/_history/，则为读取某个资源所有版本的操作
形如/[type]/_history/，则为读取所有同类型资源所有版本的操作

其中[type] 可以是Patient、Provider、Organization(可以更多)
id和vid都是string [A-Za-z0-9\-\.]{1,64}

这时候我是
1、定义一个/ 然后在里面根据拿到的uri参数的具体情况来分别处理

location / {
}
2、定义多个 location，通过编写匹配规则来精确定位每一个api
但url里又有不止一个可变动的地方，不知有没有可以参考的正则写法

--

--

yuansheng_2f16

> 这时候我是

> 1、定义一个/ 然后在里面根据拿到的uri参数的具体情况来分别处理

> location / {

> }

> 2、定义多个 location，通过编写匹配规则来精确定位每一个api

> 但url里又有不止一个可变动的地方，不知有没有可以参考的正则写法

个人比较喜欢第一个方案，后面动态扩充、收缩，只修改lua代码即可，更容易修改。目前我正在做一个超简化版本的router，因为还不够完善，暂时不太好意思拿出来。

2015-09-08 9:37 GMT+08:00 王海生 <whs8...@gmail.com>:

我后台有一套java的不过还是谢谢

在 2015年9月7日星期一 UTC+8下午5:44:37，X山鹰写道：

你可以再后端跑个nodejs的服务前面套个nginx或者openresty一样可以实现
http://expressjs.com/4x/api.html#app.param
这个是路由定义你可以看看
希望对你有帮助

Date: Mon, 7 Sep 2015 02:13:21 -0700
From: whs8...@gmail.com
To: open...@googlegroups.com
CC: eagle...@hotmail.com

Subject: Re: [openresty] location 的设计

能给个例子的链接么我是打算直接用postgrest做后端它本身就能抛http api 然后套上openresty就好了

在 2015年9月7日星期一 UTC+8下午4:00:37，X山鹰写道：

直接使用nodejs的express框架写http api哇
然后用nginx代理过去这样会比在nginx里面写会更好的

Date: Sun, 6 Sep 2015 22:48:54 -0700
From: whs8...@gmail.com
To: open...@googlegroups.com
Subject: [openresty] location 的设计

location 的设计

我现在有一组http api接口，如下所示

只有/[type]/id，则为读取某个资源最新版本的操作
形如/[type]/id/_history/vid，则为读取某个资源具体某个版本的操作
存在/[type]/?，则为查询操作，根据?后面的键值对形式的参数来处理
形如/[type]/id/_history/，则为读取某个资源所有版本的操作
形如/[type]/_history/，则为读取所有同类型资源所有版本的操作

其中[type] 可以是Patient、Provider、Organization(可以更多)
id和vid都是string [A-Za-z0-9\-\.]{1,64}

这时候我是
1、定义一个/ 然后在里面根据拿到的uri参数的具体情况来分别处理

location / {
}
2、定义多个 location，通过编写匹配规则来精确定位每一个api
但url里又有不止一个可变动的地方，不知有没有可以参考的正则写法

--

--

--

Membhis

My github: https://github.com/membphis

Our Book: OpenResty Best Practices

whs860603

惊现qq群猪
来分享指导个我嘛
我是超级新手
怕走弯路

在 2015年9月8日星期二 UTC+8下午12:25:54，YuanSheng Wang写道：

> 这时候我是
> 1、定义一个/ 然后在里面根据拿到的uri参数的具体情况来分别处理
>
>   location / {
>     }
> 2、定义多个 location，通过编写匹配规则来精确定位每一个api
> 但url里又有不止一个可变动的地方，不知有没有可以参考的正则写法

个人比较喜欢第一个方案，后面动态扩充、收缩，只修改lua代码即可，更容易修改。目前我正在做一个超简化版本的router，因为还不够完善，暂时不太好意思拿出来。

2015-09-08 9:37 GMT+08:00 王海生 <whs8...@gmail.com>:
我后台有一套java的不过还是谢谢

在 2015年9月7日星期一 UTC+8下午5:44:37，X山鹰写道：

你可以再后端跑个nodejs的服务前面套个nginx或者openresty一样可以实现
http://expressjs.com/4x/api.html#app.param
这个是路由定义你可以看看
希望对你有帮助

Date: Mon, 7 Sep 2015 02:13:21 -0700
From: whs8...@gmail.com
To: open...@googlegroups.com
CC: eagle...@hotmail.com

Subject: Re: [openresty] location 的设计

能给个例子的链接么我是打算直接用postgrest做后端它本身就能抛http api 然后套上openresty就好了

在 2015年9月7日星期一 UTC+8下午4:00:37，X山鹰写道：

直接使用nodejs的express框架写http api哇
然后用nginx代理过去这样会比在nginx里面写会更好的

Date: Sun, 6 Sep 2015 22:48:54 -0700
From: whs8...@gmail.com
To: open...@googlegroups.com
Subject: [openresty] location 的设计

location 的设计

我现在有一组http api接口，如下所示

只有/[type]/id，则为读取某个资源最新版本的操作
形如/[type]/id/_history/vid，则为读取某个资源具体某个版本的操作
存在/[type]/?，则为查询操作，根据?后面的键值对形式的参数来处理
形如/[type]/id/_history/，则为读取某个资源所有版本的操作
形如/[type]/_history/，则为读取所有同类型资源所有版本的操作

其中[type] 可以是Patient、Provider、Organization(可以更多)
id和vid都是string [A-Za-z0-9\-\.]{1,64}

这时候我是
1、定义一个/ 然后在里面根据拿到的uri参数的具体情况来分别处理

location / {
    }
2、定义多个 location，通过编写匹配规则来精确定位每一个api
但url里又有不止一个可变动的地方，不知有没有可以参考的正则写法

--

--

--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices

agentzh

Hello!

2015-09-07 16:00 GMT+08:00 X山鹰:
> 直接使用nodejs的express框架写http api哇
> 然后用nginx代理过去这样会比在nginx里面写会更好的
>

显然直接在 nginx 里面通过 Lua 实现要比代理给 nodejs 性能高得多（而且应该比直接访问 nodejs 也高得多，呵呵）。

Regards,
-agentzh

agentzh

Hello!

2015-09-07 13:48 GMT+08:00 王海生:
> 这时候我是
>
> 1、定义一个/  然后在里面根据拿到的uri参数的具体情况来分别处理
>
>
>     location / {
>
>     }
>
> 2、定义多个 location，通过编写匹配规则来精确定位每一个api
>

两种做法都成，且各有优缺点。前者比如灵活和干净，因为所有业务逻辑都在 Lua
代码中，而且甚至可以动态添加和去除入口。后者更高效一些，但相对固定，且入口信息固定在 nginx.conf
中。二者也可以混合使用，根据具体的情况。

值得一提的是，未来我打算为 OpenResty 引入一个 URI dispatcher 库，基于新的 sregex DFA 正则引擎。

Regards,
-agentzh

yuansheng_2f16

> 值得一提的是，未来我打算为 OpenResty 引入一个 URI dispatcher 库，基于新的 sregex DFA 正则引擎。

这个就超期待了。看最近微博更新的测试用例，对最后的性能、稳定性，非常赞。

2015-09-08 16:16 GMT+08:00 Yichun Zhang (agentzh) <age...@gmail.com>:

Hello!

2015-09-07 13:48 GMT+08:00 王海生:
> 这时候我是
>
> 1、定义一个/ 然后在里面根据拿到的uri参数的具体情况来分别处理
>
>
> location / {
>
> }
>
> 2、定义多个 location，通过编写匹配规则来精确定位每一个api
>

两种做法都成，且各有优缺点。前者比如灵活和干净，因为所有业务逻辑都在 Lua
代码中，而且甚至可以动态添加和去除入口。后者更高效一些，但相对固定，且入口信息固定在 nginx.conf
中。二者也可以混合使用，根据具体的情况。

值得一提的是，未来我打算为 OpenResty 引入一个 URI dispatcher 库，基于新的 sregex DFA 正则引擎。

Regards,
-agentzh

--

Membhis

My github: https://github.com/membphis

Our Book: OpenResty Best Practices

whs860603

谢春哥那我就先自己折腾折腾吧

在 2015年9月8日星期二 UTC+8下午4:16:31，agentzh写道：

Hello!

2015-09-07 13:48 GMT+08:00 王海生:
> 这时候我是
>
> 1、定义一个/ 然后在里面根据拿到的uri参数的具体情况来分别处理
>
>
> location / {
>
> }
>
> 2、定义多个 location，通过编写匹配规则来精确定位每一个api
>

两种做法都成，且各有优缺点。前者比如灵活和干净，因为所有业务逻辑都在 Lua
代码中，而且甚至可以动态添加和去除入口。后者更高效一些，但相对固定，且入口信息固定在 nginx.conf
中。二者也可以混合使用，根据具体的情况。

值得一提的是，未来我打算为 OpenResty 引入一个 URI dispatcher 库，基于新的 sregex DFA 正则引擎。

Regards,
-agentzh