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