Support for email address ( resource with .) in resource uri

[rohitjoshi]

1. I have added support for dot (.) in resource uri e.g /emails/:email/devices and request uri is /emails/[email protected]/devices
2. Updated readme to replace ngx.var.request_uri with ngx.var.uri . This will support uri without any subresources.

[mikz]

@rohitjoshi I don't think replacing all strings with constants should be done in the same PR as adding a support for .. Also, it fails the build because some are unused https://travis-ci.org/APItools/router.lua/jobs/121157963

Could you commit just the support for . so it is easier to review?

If you feel moving those constants to string improves something (like performance), i'd like see proof. I don't think it adds readability. On the contrary.

[mikz]

we definitely want to support those

[rohitjoshi]

I think adding support for dot (.) conflict with your requirement of supporting extension for the resource.

e.g you have a test case /resource/1.json where you expect resource value to be 1
By adding support for ., it will return 1.json
e.g /users/[email protected] should return [email protected]
So unless we remove support for extension, dot support will not work.

Regarding defining constants, I had ran this test long ago and most of the time JIT does optimize but with millions of requests, I was able to see the difference. I do agree performance gain may not be significant compared to readability.

[mikz]

I don't see a test testing support for the .. I just see removing support for partial matching.

The tests are testing that /:id.json extracts 1. I don't see how that could conflict with /:email matching the whole string. It might be not easy because of how it is implemented, but that does not mean it is not possible.

I can't merge such breaking functionality, sorry. I'd be fine merging it, if it would not break current tests and remove existing functionality.

[rohitjoshi]

will submit another PR with

1. email support
2. remove const strings