[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12909036#action_12909036
]
Jack Krupansky commented on CONNECTORS-98:
--
Looks good. This meets meets my expectations. Any further tweaks that might
arise would be distinct Jira issues.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
Re: [jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
I briefly reviewed the proposal wiki and it looks good good enough to move
forward. There may be revisions as we actually start using it, but this is
definitely a big step in the right direction.
-- Jack Krupansky
--
From: "Karl Wright"
Sent: Monday, September 13, 2010 4:30 AM
To:
Subject: Re: [jira] Commented: (CONNECTORS-98) API should be "pure" RESTful
with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
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)
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":__\}
would be GET outputconnections/
> and GET outputconnection/delete
> \{"connection_name":__\}
would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
\{"outputconnection":__\} would be PUT
outputconnections/
\{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908781#action_12908781
]
Karl Wright commented on CONNECTORS-98:
---
Version of API matching proposal document has been checked in.
r996524.
Actual wiki API document will require extensive update, obviously.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
Re: [jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
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) 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":__\}
> would be GET outputconnections/
> > and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> > and GET outputconnection/list would be GET outputconnections
> > and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> > 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.
>
>
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908575#action_12908575
]
Karl Wright commented on CONNECTORS-98:
---
bq. 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.)
Yes, in fact as we discussed before, the entire name must be URL-encoded using
a method like java.net.URLEncoder.encode(). However, that's not enough,
because of the "/" problem, so I proposed that BEFORE the client does the URL
encoding, it does slash-encoding as well.
bq. 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
".". 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.
Actually, since the URL encoding takes place afterwards, you can use any
character you want. So, if you tried my original proposal with your example,
you would actually get:
GET
info/outputconnections/this+updated.%2crevised+example+connection+1..0/
(I think %2c is %-encoded "+", right? Too lazy to look it up...)
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
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
".". 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/
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/
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908561#action_12908561
]
Mark Miller commented on CONNECTORS-98:
---
I agree - I think the best REST is sticking by most of the general practices as
you can / makes sense - but more importantly, just be consistent. While it can
be nice to stick to the http spec / REST gospel when you can, sometimes it just
makes sense to be a little different.
bq. (2) HTTP states that PUT should generate a 201 return when the resource is
being created.
Both PUT and POST can be used to create according to HTTP.
bq. (3) Use of plural/singular. I don't really care much. Pick something and
let me know and we'll stick with it.
I agree - it's only important to be consistant internally here - otherwise, who
cares.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908557#action_12908557
]
Karl Wright commented on CONNECTORS-98:
---
bq. http://www.infoq.com/articles/rest-introduction
This article's use of PUT vs. POST is rather different than the HTTP
specification and every other REST article's usage that I've seen so far. I
think that should remind you that there is indeed no real standard, so you run
a real chance of chasing a wil-o-the-wisp if you take everyone's individual
convention as gospel.
I think this applies to use of plural. Your articles differ on this, as do
most of the articles I read too. Really the important thing is whether you can
write a URL for every object. Nothing else is as crucial.
So I think *we* are going to have to agree on our own conventions for this API,
which may or may not agree 100% with other peoples'. Here are some proposals.
(1) We will continue to use the connection_name as the key for connection
collections, because it is, but we encode it in some way, because we have to.
Please acknowledge that this is acceptable.
(2) HTTP states that PUT should generate a 201 return when the resource is
being created. That implies that you should use PUT to create a resource.
That's fine for resources that include their own primary key, such as
connections, but does not work for jobs, which mint a unique ID when they are
created. For those kinds of entities, I believe the right thing to do is use a
POST on the parent, e.g. POST /jobs, but some reference materials are pretty
loose about this kind of thing. But then the issue is, how exactly is the new
job's ID supposed to be returned to the caller? Because that obviously must
happen.
One way is to provide a GET command that just returns a unique ID, and separate
out the id minting from the job saving. That seems cumbersome, but will be
necessary if there's no other way. Or, is POST allowed to return a json
response containing the ID? None of the references so far demonstrates a
comparable model - or maybe I missed it. Can you confirm what should be done
here.
(3) Use of plural/singular. I don't really care much. Pick something and let
me know and we'll stick with it.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908554#action_12908554
]
Karl Wright commented on CONNECTORS-98:
---
bq. On closer examination, all of the examples I have found use an "id" rather
than a name in the path. Typically a number or maybe alphanumeric with hyphens.
So, we should consider revisiting that aspect of the API. That avoids the slash
issue.
bq.
bq. So, presumably an app using the API would query the list of connections and
the JSON would provide the id for each connection and the the app would use
those ids for API calls.
For connections, there are no id's. The connection_name is the primary key for
this entity. So unless you want a wholesale rework of the schema as well as a
rewrite of some 50% of acf code, that is not an option.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908244#action_12908244
]
Jack Krupansky commented on CONNECTORS-98:
--
And that last reference provides examples that illustrate the convention of
using plurals. For example:
GET /customers/1234 HTTP/1.1
http://www.infoq.com/articles/rest-introduction
The goal here is to use a common style so that people approaching the ACF API
will not be surprised and have to re-learn things to use this API.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908240#action_12908240
]
Jack Krupansky commented on CONNECTORS-98:
--
On closer examination, all of the examples I have found use an "id" rather than
a name in the path. Typically a number or maybe alphanumeric with hyphens. So,
we should consider revisiting that aspect of the API. That avoids the slash
issue.
So, presumably an app using the API would query the list of connections and the
JSON would provide the id for each connection and the the app would use those
ids for API calls.
Another reference:
http://www.infoq.com/articles/rest-introduction
"Give every 'thing' an ID"
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908190#action_12908190
]
Jack Krupansky commented on CONNECTORS-98:
--
I am reading IETF RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax,
section 3.3, "Path", among other things.
See:
http://www.ietf.org/rfc/rfc3986.txt
No conclusion yet.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908154#action_12908154
]
Karl Wright commented on CONNECTORS-98:
---
bq. My model is that a name should occupy only a single path component.
That implies double encoding, because even if your standard,
illegal-character-escaping single level of encoding happens to convert "/" into
"%2F", the app server will turn it back into "/" before you get to see it.
FWIW, there is nothing that stops you from saying "this first part of the path
is parsed by me, and the rest of the path is interpreted as a string that can
contain slash characters." Remember, slash characters are LEGAL in URLs. I
don't know what you are reading but a quick glance at just about any url should
convince you of this.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908148#action_12908148
]
Jack Krupansky commented on CONNECTORS-98:
--
I am still pondering this embedded slash issue and checking into some things
related to it. Maybe Monday I'll have something more concrete to say.
For example, I want to make sure I understand the rules for what a path can
have in it in a URI and whether simply placing a name at the tail of the path
means it can have slashes or other reserved characters in it. My model is that
a name should occupy only a single path component.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908125#action_12908125
]
Karl Wright commented on CONNECTORS-98:
---
It turns out that arguments to some existing connector info methods are also
potentially names that can have "/" characters in them. That's unfortunate
because I cannot then avoid double-encoding *something*.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907957#action_12907957
]
Karl Wright commented on CONNECTORS-98:
---
Created the full cwiki proposal:
https://cwiki.apache.org/confluence/display/CONNECTORS/REST+API+proposal
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
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/ ()
outputconnection/save (output_connection_object) -> PUT outputconnection
(output_connection_object)
outputconnection/delete (connection_name) -> DELETE
outputconnection/ ()
outputconnection/list () -> GET outputconnections ()
outputconnection/checkstatus (connection_name) -> GET
status/outputconnection/ ()
outputconnection/execute/ (connection_name, arguments) -> GET
info//outputconnection/ ()
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/ ()
... 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907934#action_12907934
]
Karl Wright commented on CONNECTORS-98:
---
There are currently no restrictions on characters in ACF fields, and I'd be
loathe to start adding them just to support one person's idea of the proper URL
over another's.
As for bypassing GetPathInfo, I don't think that's a good idea either. The
purpose of that decoding step is to handle non-legal URI characters and non
7-bit-ascii, both of which we really need.
I think the choice will be between putting all such keys at the end of the URL,
or double-escaping them. But I still have not decided which I prefer.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907875#action_12907875
]
Jack Krupansky commented on CONNECTORS-98:
--
It makes sense that GetPathInfo would have removed escapes from the URL. So,
either we don't use % escaping or bypass GetPathInfo and manually decode.
Maybe we could use backslash for escaping. I'm not sure whether it needs to be
% escaped as well.
This is only needed if the user has one of the reserved special characters in a
name. It would be an issue if it was something that users commonly needed, but
it seems like more of an edge case rather than a common case.
Encourage people to use alphanumeric, "-", and "_" for names and it won't be an
issue for them.
And, the real point of the API is access from code. We can provide helper
functions for working with names and building API paths.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907804#action_12907804
]
Karl Wright commented on CONNECTORS-98:
---
Jack,
It looks like the servlet container does the decoding. This command:
curl "http://localhost:8345/acf-api-service/json/%2f/ha";
yields this request.getPathInfo() string:
/json///ha
So, using %-encoding is reasonable only for non-latin-1 characters, and a
SECOND level of encoding will be necessary to make sure "/" characters in the
name don't break the parsing. This seems too onerous to me for a user of the
API to get right.
I therefore want to ponder this for a bit and see if there is any easy way to
get this right without burdening the user. If not, I think we should adopt my
proposal instead of yours.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907774#action_12907774
]
Karl Wright commented on CONNECTORS-98:
---
I don't think you mean to claim that '/' characters are illegal in urls, do
you? If so we would not be having this discussion.
Nevertheless, it's certainly possible to %-encode '/' characters within names.
I am not sure at what level decoding happens though. If the decoding is done
by the servlet container, doing character stuffing in this way will not help us.
Even if we get to do our own decoding, recognize that we'd in essence be
establishing our own standard here, and may need to write our own custom
encoder/decoder logic.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907758#action_12907758
]
Jack Krupansky commented on CONNECTORS-98:
--
re: " the cannot itself contain "/" characters, or it won't be
uniquely parseable"
Elsewhere I noted that URI-reserved characters need to be encoded with the "%"
notation, so this is not a fatal problem.
reserved= ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907751#action_12907751
]
Karl Wright commented on CONNECTORS-98:
---
It occurs to me that this is also unworkable, for the same character-stuffing
reasons:
outputconnection/execute/ (connection_name, arguments) -> GET
outputconnectionrequest// ()
At issue is the following the . These would need to
be reversed:
outputconnection/execute/ (connection_name, arguments) -> GET
request//outputconnection/ ()
or:
outputconnection/execute/ (connection_name, arguments) -> GET
request/outputconnection// ()
Problem is that for either one of these the cannot itself contain "/"
characters, or it won't be uniquely parseable. That limits input argument
structure even more. However, it is still acceptable under current usage,
because right now we're not doing anything terribly complex with this feature.
FWIW, I think I prefer the former to the latter option.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907741#action_12907741
]
Karl Wright commented on CONNECTORS-98:
---
bq. Sure, we could go that route, and list the arguments as path elements, but
I think a JSON object (array list of arguments) is acceptable.
This makes me wonder whether you really mean to stick with the REST style
described in the very document you submitted for my review. Either the API is
consistent with that, or it's not.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907739#action_12907739
]
Karl Wright commented on CONNECTORS-98:
---
I don't like stuff after the connection name because that would effectively
prohibit "/" characters in the connection name, unless you do some kind of
character stuffing.
An alternative would be to put the verb first, e.g.:
outputconnection/checkstatus (connection_name) -> GET
status/outputconnection/ ()
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907736#action_12907736
]
Jack Krupansky commented on CONNECTORS-98:
--
re: "We could not pass (arguments) except as part of the path."
Sure, we could go that route, and list the arguments as path elements, but I
think a JSON object (array list of arguments) is acceptable.
So, I'd go with the latter (JSON.)
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907735#action_12907735
]
Jack Krupansky commented on CONNECTORS-98:
--
I think status is probably technically okay since it is disambiguated by number
path elements, but it could be moved to the end:
GET outputconnections//status ()
vs.
GET outputconnections/status/ ()
Same for execute/request:
GET outputconnections//request/ (arguments)
vs.
GET outputconnections/request// (arguments)
That way the connection name is always in the same position.
So, I'd revise my counter-proposal that way.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907729#action_12907729
]
Karl Wright commented on CONNECTORS-98:
---
By the way, your proposal:
outputconnection/execute/ (connection_name, arguments) -> GET
outputconnections/request// (arguments)
... would not meet the REST-Web-Services definition. We could not pass
(arguments) except as part of the path.
Also, in order to avoid conflicts between connection names and commands like
"status", it seems clear to me that we would have to change the first part of
the path to disambiguate these two. For example:
outputconnection/get (connection_name) -> GET
outputconnection/ ()
outputconnection/save (output_connection_object) -> PUT outputconnection
(output_connection_object)
outputconnection/delete (connection_name) -> DELETE
outputconnection/ ()
outputconnection/list () -> GET outputconnections ()
outputconnection/checkstatus (connection_name) -> GET
outputconnectionstatus/ ()
outputconnection/execute/ (connection_name, arguments) -> GET
outputconnectionrequest// ()
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907723#action_12907723
]
Jack Krupansky commented on CONNECTORS-98:
--
Karl asks how to "handle connection names that are non-7-bit-ascii".
I believe that non-7-bit-ASCII and URI-reserved chars would simply be escaped
using the "%" notation.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907712#action_12907712
]
Jack Krupansky commented on CONNECTORS-98:
--
Some RESTful resource doc:
http://en.wikipedia.org/wiki/Representational_State_Transfer
http://www.xfront.com/REST-Web-Services.html
http://www.oracle.com/technetwork/articles/javase/table3-138001.html
The idea of using a plural is that it is the name of the collection and the
qualifier (name or argument object) provides the specificity.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907704#action_12907704
]
Karl Wright commented on CONNECTORS-98:
---
How do you propose to handle connection names that are non-7-bit-ascii?
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907705#action_12907705
]
Karl Wright commented on CONNECTORS-98:
---
Also, can you point me at a REST reference which states that the key for the
object being operated upon must appear in the path. I have looked but can find
no such standard anywhere.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907702#action_12907702
]
Jack Krupansky commented on CONNECTORS-98:
--
Karl, I did a quick read of your suggestions and mostly they seem fine,
including keeping the JSON usage as is, but to be more purely RESTful the
connection_name should be part of the path in those cases where it would have
been a standalone name, although for PUT it was simply redundant as you noted.
Another nuance is to consistently refer to outputconnections as plural.
My counter-proposal:
outputconnection/get (connection_name) -> GET
outputconnections/ ()
outputconnection/save (output_connection_object) -> PUT outputconnections
(output_connection_object)
outputconnection/delete (connection_name) -> DELETE
outputconnections/ ()
outputconnection/list () -> GET outputconnections ()
outputconnection/checkstatus (connection_name) -> GET
outputconnections/status/ ()
outputconnection/execute/ (connection_name, arguments) -> GET
outputconnections/request// (arguments)
Comments?
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907686#action_12907686
]
Karl Wright commented on CONNECTORS-98:
---
So Jack,
I've worked through a small subset of the current API, and would like to make
suggestions. Basically, I'm suggesting equivalents for the following:
outputconnection/list
outputconnection/get
outputconnection/save
outputconnection/delete
outputconnection/checkstatus
outputconnection/execute/
First, it is worth noting that each of these commands has a potential error
response, and in some cases, a null response. For example:
outputconnection/get
can yield:
{"outputconnection":} OR { } OR
{"error":}
Thus, the reason that I qualified the actual returned object with
"outputconnection" was to distinguish this case from the other cases, one of
which represents "object not found", and the other which represents an error.
So I don't think that we should muck with the response since the current design
seems both necessary and sufficient.
Second, in the brave new REST world, not all of these are going to be able to
have the same path. There are simply too many operations for that to covered
with the available REST verbs. So we will have to have some other way of
describing those operations.
Third, although the ".../execute/..." command sounds like it causes something
to happen, in reality it is in fact always an information retrieval operation.
Thus it should always use the "GET" verb.
So, this is what I think is a reasonable proposal:
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 outputconnection/status
(connection_name)
outputconnection/execute/ (connection_name, arguments) -> GET
outputconnection/request/ (connection_name, arguments)
Effectively, this means we preserve the input and output arguments completely
as-is, and simply change the verb and predicate to suit the REST style.
Comments?
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907622#action_12907622
]
Karl Wright commented on CONNECTORS-98:
---
I believe anyone has privileges sufficient to create a new page for the
connectors wiki project. I suggest that you do that so that your proposal is
clear to all.
I'd also prefer that you change the actual json for objects as little as
possible. Your suggestion to remove the descriptive "outputconnection" label
comes under that heading. I thought this all through carefully - the code here
has less flexibility because it is basically an internal representation of both
json and xml, so some aspects of the way things are done are not going to be
straightforward to pull off. If we also really want to make changes like that,
fine, but it's a whole different project, in my view.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907617#action_12907617
]
Jack Krupansky commented on CONNECTORS-98:
--
It sounds reasonable that the connection name is not needed in the path when
creating from a JSON object that already has the name in it.
So, instead of:
PUT outputconnections/
{"outputconnection":}
we could have:
PUT outputconnections {"outputconnection":}
Further, I don't think we need the extra level of object, so that could be:
PUT outputconnections {}
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907614#action_12907614
]
Jack Krupansky commented on CONNECTORS-98:
--
I have looked at the code a bit but not made any actual progress at a patch, so
you can go ahead and take a crack at it. Yes, I'll do the transformation table.
As far as updating the wiki, do I have privileges to do that?
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907579#action_12907579
]
Karl Wright commented on CONNECTORS-98:
---
The current wiki URL is
https://cwiki.apache.org/confluence/display/CONNECTORS/Programmatic+Operation+of+ACF
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907574#action_12907574
]
Karl Wright commented on CONNECTORS-98:
---
Also, I take issue with this:
bq. PUT outputconnections/
{"outputconnection":}
The connection name is actually already part of the json object - and must be
so, or you couldn't get a list of these things - so you'd be specifying it
*twice* if you did it this way? That seems wrong to me. Indeed, the
underlying way all of the objects in ACF are managed is as follows:
create()->object (where you add your own key)
load(key) -> object (which has embedded key)
save(object)
list() -> list of objects (each of which has embedded key)
delete(key)
Is there room in a strict interpretation of REST for this eminently sensible
way of managing objects?
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907538#action_12907538
]
Karl Wright commented on CONNECTORS-98:
---
Has there been any progress made on this issue?
I'm going to need some definition very shortly at least for what you intend to
do - or if you don't want to do it, I'll take a crack at it. Specifically, can
you write a wiki page that has tables similar to the one that currently
describes the API, which instead has your new API? I think this is a
straightforward transformation, although you will need a new column ("HTTP
verb").
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903559#action_12903559
]
Jack Krupansky commented on CONNECTORS-98:
--
I'll be mostly looking through code and thinking it through and looking at the
API string changes first, so I may not touch any code for another week, if not
longer. Feel free to rename or refactor code at will. I'll probably let you
know in advance of what changes I expect to make in the code.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903556#action_12903556
]
Karl Wright commented on CONNECTORS-98:
---
Jack, if you intend to work on this, can you give me an idea of roughly when I
can expect to see something? It looks like there's going to be another
renaming exercise, and I'd rather not step too hard on ongoing work, so please
us apprised of your schedule/progress.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902983#action_12902983
]
Jack Krupansky commented on CONNECTORS-98:
--
Karl says "I await your patch."
Point well made. There is a great starting point with the current code. A bit
of refactoring required.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902982#action_12902982
]
Jack Krupansky commented on CONNECTORS-98:
--
Karl asks "what do you plan to do for the list and execute verbs?"
List would be a GET and execute would be PUT.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902964#action_12902964
]
Karl Wright commented on CONNECTORS-98:
---
By the way, what do you plan to do for the list and execute verbs?
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902948#action_12902948
]
Karl Wright commented on CONNECTORS-98:
---
I await your patch.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902941#action_12902941
]
Mark Miller commented on CONNECTORS-98:
---
bq. Also, POST should be usable as an alternative to PUT for API calls that
have large volumes of data.
That shouldn't be necessary at all.
> 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":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> 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.
