I have updated the wiki proposal document. I now have working code consistent with that implementation, which I will check in as soon as you confirm that you are happy with the design, and when I have tested it more.
Karl On Sun, Sep 12, 2010 at 8:28 PM, Jack Krupansky (JIRA) <j...@apache.org>wrote: > > [ > https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908581#action_12908581] > > Jack Krupansky commented on CONNECTORS-98: > ------------------------------------------ > > Just to confirm, as requested, that I am comfortable sticking with > connection name (and job name, etc.) in API paths as opposed to using a more > abstract "id" since we seem to have an encoding convention to deal with > slash so that an ACF object name can always be represented using a single > HTTP path segment. Names clearly feel more natural and will be easier to > use, both for app code using the ACF API and for CURL and other scripting > tools. > > > > > > API should be "pure" RESTful with the API verb represented using the HTTP > GET/PUT/POST/DELETE methods > > > ----------------------------------------------------------------------------------------------------- > > > > Key: CONNECTORS-98 > > URL: https://issues.apache.org/jira/browse/CONNECTORS-98 > > Project: Apache Connectors Framework > > Issue Type: Improvement > > Components: API > > Affects Versions: LCF Release 0.5 > > Reporter: Jack Krupansky > > Fix For: LCF Release 0.5 > > > > > > (This was originally a comment on CONNECTORS-56 dated 7/16/2010.) > > It has come to my attention that the API would be more "pure" RESTful if > the API verb was represented using the HTTP GET/PUT/POST/DELETE methods and > the input argument identifier represented in the context path. > > So, GET outputconnection/get \{"connection_name":_<connection_name>_\} > would be GET outputconnections/<connection_name> > > and GET outputconnection/delete \{"connection_name":_<connection_name>_\} > would be DELETE outputconnections/<connection_name> > > and GET outputconnection/list would be GET outputconnections > > and PUT outputconnection/save > \{"outputconnection":_<output_connection_object>_\} would be PUT > outputconnections/<connection_name> > \{"outputconnection":_<output_connection_object>_\} > > What we have today is certainly workable, but just not as "pure" as some > might desire. It would be better to take care of this before the initial > release so that we never have to answer the question of why it wasn't done > as a "proper" RESTful API. > > BTW, I did check to verify that an HttpServlet running under Jetty can > process the DELETE and PUT methods (using the doDelete and doPut method > overrides.) > > Also, POST should be usable as an alternative to PUT for API calls that > have large volumes of data. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >