[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908573#action_12908573
]
Jack Krupansky commented on CONNECTORS-98:
------------------------------------------
re: Spaces in connection names...
A URL path sent by a cleint cannot have an unencoded space. Typically, a space
is encoded as "+" or "%20". The final path retrieved by the server app will
have the expanded spaces, but the path to be sent via HTTP from the client must
be encoded since a space is the delimiter between the path and the HTTP version
as per IETF RFC 2616 Sec 5.1:
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
See:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html
The first upshot of this is that the client needs to encode spaces as "+" or
"%20". Ditto for other reserved chars (described in an earlier comment.)
A second upshot of this is that we can't use ".+" in the original path from the
client to encode slash since it would come through to the ACF server app as
".<space>". So, either the client would have to write ".%2B" or we pick some
other encoding. Lacking some more preferred choice, we could simply propose
".-" as our encoding for slash. Almost any (non-reserved) char will do.
Another proposed encoding for slash: double the slash when it is to be embedded
in a name and then the adjacent path segments will be merged with a single
slash between. I don't like this since it is not encoding the full name as a
single path segment, but it may be the cleanest way of dealing with slash. An
example, encoding the name "this updated/revised example connection 1.0":
GET
info/outputconnections/this+updated//revised+example+connection+1.0/<command>
Personally, I lean towards an encoding convention that can result in encoding
the name as a single path segment. With the ".." and ".-" encoding convention
this example would be:
GET
info/outputconnections/this+updated.-revised+example+connection+1..0/<command>
> 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.
