Possible enhancement - default "options" method

[Steven Neiland]

So I've made a modification to my copy of taffy to create a default "options" method for resources. Basically what it does is if an options method is not defined in a resource (my version of) taffy uses an standard options method I defined in the taffycore.resources cfc.

This default options method uses the resource file meta data to generate a representation of the different methods available in the resource.The parameters are read from the function arguments, the description from the hint attribute etc. For example a users member resource with a GET method generates this.

{

• "URI": "/users/{userId}",
• "METHODS": [
  • {
    • "PARAMETERS": [
      • {
        • "required": true,
        • "name": "userId",
        • "type": "numeric"
        }
      ],
    • "DESCRIPTION": "Returns a single user record",
    • "METHOD": "get"
    },
  • {
    • "PARAMETERS": [ ],
    • "DESCRIPTION": "Returns the different options available for a resource",
    • "METHOD": "options"
    }
  ]

}

Does anybody see any value in this. Note I have only tested on Railo so far, but if people see any value to it I can test on CF8 and submit a pull request to GH.

[Steven Neiland]

p.s. This is returned in the body of the response

[Adam Tuttle]

Do you have any documentation to support that OPTIONS should return a body at all? The current implementation is based on the requirements for CORS AJAX requests -- for example jQuery sends specific headers and looks for specific return headers to determine if the request that it's about to make will be allowed by the server's CORS policy.

I can see how having some documentation in the options body would be useful to humans, though.

Adam

On Fri, Apr 18, 2014 at 7:44 PM, Steven Neiland <steven....@gmail.com> wrote:

p.s. This is returned in the body of the response

--
You received this message because you are subscribed to the Google Groups "Taffy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taffy-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steven Neiland]

From my research at the moment the specification does not define a use of the body, but it does allow it to be returned provided the content type of said body is indicated.

It might help to give you an idea what I am trying to achieve in my own api implementation so you can see the potential use of this.

What I am trying to achieve in my api is to make it discoverable i.e. I can give someone a link to the root of it and they can discover how it works by following the branches (without giving them access to the dashboard). I'm discovering it is actually supposed to be a key part of rest as envisioned by Ted Nelson. While I'm not trying to go as far as HATEOAS I am trying to make it almost self documenting.

I'm doing this in two ways.
#1: Every returned resource contains links to any nested values. So a group member might contain a link to the members uri.

ie. GET /groups/1 returns
{

groupId: 1
, name: "example"
, links: [

{

name: "members"
,uri: "/groups/1/members"

},
{

name: "events"
,uri: "/groups/1/events"

}

]

}

#2 This options method to return all possible method calls on this resource. I am still toying with the idea of adding something to the get response that contains the json being generated in the "options" body instead. This might actually be a better implementation but I'm trying to follow the rest principles as close as I can (as I understand them).

So is this necessary, not at all. Is it more work, yes. I do though think could be a good supplement for proper documentation.

[Adam Tuttle]

Send a pull request (don't forget your feature branch) that uses a variables.framework setting to enable/disable it (disabled by default) -- I'm thinking variables.framework.optionsBody = true, but if you feel like it should be something else, make your case! :)

Most importantly: Whatever you do needs to be CF8 compatible and should be as efficient as possible -- that means no more than 1 or 2 IF-checks when it's disabled, and really efficient when enabled. You might want to do that by improving what's cached about each resource presently. Dump out application._taffy and have a look at what's being stored for function metadata/etc currently. Might be as simple as adding a few more bits to that.

Jump through those hoops for me and I'll be happy to merge it in. :)

Adam

[Steven Neiland]

Thanks adam. Im on vacation this week so ill work through the changes and get a cf8 virtual machine running to test it before I send a pull request.

Before I do though do you see my logic for this? Can you think of a better way go achieve this?

[Adam Tuttle]

Seems reasonable enough. The only suggestion I have is to look at what Taffy is storing in the application scope and see if some or all of what you need is there already. You may be able to piggy back on it, and if you don't need much more then you could add to it, too.

On Apr 20, 2014 1:56 PM, "Steven Neiland" <steven....@gmail.com> wrote:

Thanks adam. Im on vacation this week so ill work through the changes and get a cf8 virtual machine running to test it before I send a pull request.

Before I do though do you see my logic for this? Can you think of a better way go achieve this?