Adding a regular queryString calling capability for all endpoints

[marbetschar]

I feel like all Taffy endpoints should be callable with a regular query string such as the following:

https://api.taffy.com/v1/index.cfm?endpoint=/my/search&method=get&term=mySearch

The reason why is, due to the Java application server specification only one wildcard per SEO url-pattern can be used. That said, we have to add any kind of SEO which points not exactly to the webroot to the Tomcat server configuration (web.xml):

<url-pattern>/v1/index.cfm/*</url-pattern>
<url-pattern>/v2/index.cfm/*</url-pattern>
<url-pattern>/index.cfm/*</url-pattern>

In cases where Taffy is used as a standalone API these things may be setup manually. But we have some cases where Taffy just serves the need of some business logic which should be available externally (for example as part of a mura plugin). In these cases we don't have any environment control at all.

In ColdFusion 10 this works just fine, since Adobe has made modifications to Tomcats default behaviour to support backwards compatibility to JRun. On Railo Taffy doesn't run at all in this cases - due to Tomcat can't find any mapping present for the mura plugin URL :(

http://www.murasite.com/plugins/myplugin/api/index.cfm/my/search

Additionally if this capability gets added to Taffy, endpoints got triggerable from devices which may not support all HTTP verbs such as the following:

https://api.taffy.com/v1/my/search?method=put&term=mySearch

[atuttle]

I've thought about doing something similar for a while now but never really got around to it.

The limitation seems to be imposed by the Java layer. Some app servers support multiple wildcards (e.g. Jetty).

It's definitely a major change, especially if we were to break the existing url support. At least a 2.0 change, if not later.

[marbetschar]

The limitations are part of the Java servlet specification v2.4 (Section "SRV.11.2 Specification of Mappings"):
http://download.oracle.com/otndocs/jcp/servlet-2.4-fr-spec-oth-JSpec/

So any java application server which does support multiple wildcards does not behalf as the standard describes - thats why Adobe has made their modifications to Tomcat:
http://blogs.coldfusion.com/post.cfm/what-s-the-deal-with-tomcat-in-coldfusion-10

I'm neither a fan of "customizing a standard product" nor of the wildcard limitations given by the spec. Unfortunately adding this queryString calling capability seems for me to be the easiest way to achieve compatibility in the circumstances described.

Not to be able to call API functions per queryString prevents me from using Taffy in a lot of circumstances as we are rely fully on Railo over here. Maybe a "two-step-implementation" of the described features may makes sense and gives me the ability to use Taffy in all circumstances soon.

The first step:
If cgi.path_info is empty, Taffy fully relies on cgi.query_string to figure out the endpoint by using the "endpoint" query variable. I don't know exactly if the method should then be present too or it can just be passed as before (as HTTP verb). I think the implementation here shouldn't be a big deal and can be done fairly quick?

The second step:
The major rewrite you been talking about before to support "endpoint", "method" etc. which then will be included in 2.0

[marbetschar]

What I've missed before to point out:
If you like the idea of a "two step implementation" I'll wrap my head around it to implement the first step into the current version!

[atuttle]

Not sure if you're aware, Taffy already supports HTTP Method Tunneling, which is a REST standard for clients that aren't capable of verbs other than get/post.

You send a POST request the header:

X-HTTP-Method-Override: PUT

But I agree that being able to specify the REST endpoint via a standard query string parameter would be a nice addition.

[marbetschar]

Cool - wasn't aware of this Feature in Taffy! I'll have a look at the endpoint param and submit a Pull request.

Am 03.01.2013 um 15:47 schrieb Adam Tuttle notifications@github.com:

Not sure if you're aware, Taffy already supports HTTP Method Tunneling, which is a REST standard for clients that aren't capable of verbs other than get/post.

You send a POST request the header:

X-HTTP-Method-Override: PUT
But I agree that being able to specify the REST endpoint via a standard query string parameter would be a nice addition.

—
Reply to this email directly or view it on GitHub.

[atuttle]

Name it _endpoint or (if this is legal, I don't know if it is) $endpoint, that way it's less likely to conflict with resource parameter names.

[marbetschar]

Mhm - I'm not a big fan of prefixing variables. I would prefer to just name it to what it exactly is, so "endpoint" feels right to me. But I can see this may conflict with resource parameter names.

What about making the name of the param configurable inside of your variables.framework configuration struct? Such Sean has done with "preserveKeyURLKey" which defaults to "fw1pk" in FW/1?

I'm thinking about a variables.framework.endpointURLKey = 'endpoint' - does this sounds good to you?

[atuttle]

That works. How about variables.framework.endpointParam?

[marbetschar]

In my opinion the endpointURLKey naming is more obvious as it's showing the exact purpose of the setting. But if you feel more comfortable with endpointParam I'll choose this name.

[atuttle]

I feel like "key" only describes it when you think of the URL -scope- which is not a natural thing for most people, but a query string parameter is common between all platforms. What about endpointURLParam?

[marbetschar]

variables.framework.endpointURLParam - sounds nice to me :) Can't wait to put this into Taffy right now - how may I update my fork so I can see the 1.3 - develop branch?

[atuttle]

Well, easiest would probably be just to trash and re-fork. But I assume you have working changes you don't want to lose.

I can't remember the exact syntax off the top of my head but it's going to be something like this:

git remote add git@github.com:atuttle/Taffy.git upstream
git pull upstream 1.3-dev
git checkout {your-branch}
git merge 1.3-dev

Then I think you'd make sure you set the FROM of your pull request to your branch, and the TARGET to be atuttle:1.3-dev...

Then again, maybe you're supposed to treat your fork as a branch of mine, get everything into master of your fork, and then I would merge that into my 1.3-dev branch... I'm not entirely sure. :)

[atuttle]

Resolved by #117