[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907724#action_12907724
]
Karl Wright commented on CONNECTORS-98:
---------------------------------------
bq. http://en.wikipedia.org/wiki/Representational_State_Transfer
This reference says nothing of interest pertaining to the questions asked. It
would seem that my proposal and yours both qualify as RESTful API's given this
description.
bq. http://www.xfront.com/REST-Web-Services.html
This reference points out that REST is not a standard, it is a style. It
establishes a goal of modeling all resources that you would manipulate or
access with URLs. Thus, one needs to decide what the resource is, before one
can decide what the url is. Unfortunately, it doesn't look to me like this
reference's model is compatible with input arguments of any kind, except on PUT
operations. That's going to mean a less flexible infrastructure to work with
if we adopt this in strict form.
The other ramification is that all paths (which, after all, now must contain
all the input arguments) must be url-encoded utf-8, as per the w3c standard.
My question is whether we really ought to go to the extreme of prohibiting
input arguments for GET operations, as the second document would seem to
recommend.
> 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.
