[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907942#action_12907942
]
Karl Wright commented on CONNECTORS-98:
---------------------------------------
Actually, I realize that I *have* decided. Double-encoding will be too
confusing. There is furthermore no reason not to put the connection name at
the end of the url in all cases - in fact, it naturally works best that way, in
my view. Your comment about not using slashes in names may not apply to
end-users, who will be creating these names, but it certainly *does* apply to
the one case I was worried about: creating connector-specific command names.
So I think it's settled.
The final proposal, which I think is the only one that's going to work in all
dimensions, is the following:
outputconnection/get (connection_name) -> GET
outputconnection/<connection_name> ()
outputconnection/save (output_connection_object) -> PUT outputconnection
(output_connection_object)
outputconnection/delete (connection_name) -> DELETE
outputconnection/<connection_name> ()
outputconnection/list () -> GET outputconnections ()
outputconnection/checkstatus (connection_name) -> GET
status/outputconnection/<connection_name> ()
outputconnection/execute/<command> (connection_name, arguments) -> GET
info/<command>/outputconnection/<connection_name> ()
There will, of course, be similar "status" and "info" urls for all other
connection types. The constant here is whenever you see "/outputconnection/"
it is followed by the output connection name. That is why I did not suggest
"list/outputconnection", because that breaks that consistency, but I could be
convinced to do that instead of using the plural. I could have turned the
whole thing around but then we would have either parsing conflicts or you'd
need to add more to the url:
outputconnection/get (connection_name) -> GET
outputconnection/instance/<connection_name> ()
... and I didn't think you'd like that.
This will, of course, set the style for all of the rest of the URLs too. I'll
create the full proposal today, just to be sure there are no gotchas.
Note that the things we must GIVE UP for REST are:
(1) Arbitrarily complex JSON arguments to individual connector commands
(2) Commands with "/" in them, to individual connectors
> 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.
