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.
>
>

Reply via email to