You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by "Jack Krupansky (JIRA)" <ji...@apache.org> on 2010/08/26 18:25:56 UTC
[jira] Created: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
-----------------------------------------------------------------------------------------------------
Key: CONNECTORS-98
URL: https://issues.apache.org/jira/browse/CONNECTORS-98
Project: Apache Connectors Framework
Issue Type: Improvement
Components: API
Affects Versions: LCF Release 0.5
Reporter: Jack Krupansky
Fix For: LCF Release 0.5
(This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
It has come to my attention that the API would be more "pure" RESTful if the API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the input argument identifier represented in the context path.
So, GET outputconnection/get \{"connection_name":_<connection_name>_\} would be GET outputconnections/<connection_name>
and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
and GET outputconnection/list would be GET outputconnections
and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by Jack Krupansky <ja...@lucidimagination.com>.
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" <da...@gmail.com>
Sent: Monday, September 13, 2010 4:30 AM
To: <co...@incubator.apache.org>
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)
> <ji...@apache.org>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":_<connection_name>_\}
>> would be GET outputconnections/<connection_name>
>> > and GET outputconnection/delete
>> > \{"connection_name":_<connection_name>_\}
>> would be DELETE outputconnections/<connection_name>
>> > and GET outputconnection/list would be GET outputconnections
>> > and PUT outputconnection/save
>> \{"outputconnection":_<output_connection_object>_\} would be PUT
>> outputconnections/<connection_name>
>> \{"outputconnection":_<output_connection_object>_\}
>> > What we have today is certainly workable, but just not as "pure" as
>> > some
>> might desire. It would be better to take care of this before the initial
>> release so that we never have to answer the question of why it wasn't
>> done
>> as a "proper" RESTful API.
>> > BTW, I did check to verify that an HttpServlet running under Jetty can
>> process the DELETE and PUT methods (using the doDelete and doPut method
>> overrides.)
>> > Also, POST should be usable as an alternative to PUT for API calls that
>> have large volumes of data.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>
Re: [jira] Commented: (CONNECTORS-98) API should be "pure" RESTful
with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by Karl Wright <da...@gmail.com>.
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) <ji...@apache.org>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":_<connection_name>_\}
> would be GET outputconnections/<connection_name>
> > and GET outputconnection/delete \{"connection_name":_<connection_name>_\}
> would be DELETE outputconnections/<connection_name>
> > and GET outputconnection/list would be GET outputconnections
> > and PUT outputconnection/save
> \{"outputconnection":_<output_connection_object>_\} would be PUT
> outputconnections/<connection_name>
> \{"outputconnection":_<output_connection_object>_\}
> > What we have today is certainly workable, but just not as "pure" as some
> might desire. It would be better to take care of this before the initial
> release so that we never have to answer the question of why it wasn't done
> as a "proper" RESTful API.
> > BTW, I did check to verify that an HttpServlet running under Jetty can
> process the DELETE and PUT methods (using the doDelete and doPut method
> overrides.)
> > Also, POST should be usable as an alternative to PUT for API calls that
> have large volumes of data.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Wright resolved CONNECTORS-98.
-----------------------------------
Resolution: Fixed
Updated the wiki document describing the API. This should complete work on the ticket.
> API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
> -----------------------------------------------------------------------------------------------------
>
> Key: CONNECTORS-98
> URL: https://issues.apache.org/jira/browse/CONNECTORS-98
> Project: Apache Connectors Framework
> Issue Type: Improvement
> Components: API
> Affects Versions: LCF Release 0.5
> Reporter: Jack Krupansky
> Fix For: LCF Release 0.5
>
>
> (This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
> It has come to my attention that the API would be more "pure" RESTful if the API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the input argument identifier represented in the context path.
> So, GET outputconnection/get \{"connection_name":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908581#action_12908581 ]
Jack Krupansky commented on CONNECTORS-98:
------------------------------------------
Just to confirm, as requested, that I am comfortable sticking with connection name (and job name, etc.) in API paths as opposed to using a more abstract "id" since we seem to have an encoding convention to deal with slash so that an ACF object name can always be represented using a single HTTP path segment. Names clearly feel more natural and will be easier to use, both for app code using the ACF API and for CURL and other scripting tools.
> API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
> -----------------------------------------------------------------------------------------------------
>
> Key: CONNECTORS-98
> URL: https://issues.apache.org/jira/browse/CONNECTORS-98
> Project: Apache Connectors Framework
> Issue Type: Improvement
> Components: API
> Affects Versions: LCF Release 0.5
> Reporter: Jack Krupansky
> Fix For: LCF Release 0.5
>
>
> (This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
> It has come to my attention that the API would be more "pure" RESTful if the API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the input argument identifier represented in the context path.
> So, GET outputconnection/get \{"connection_name":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Mark Miller (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Wright reassigned CONNECTORS-98:
-------------------------------------
Assignee: Karl Wright
> 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
> Assignee: Karl Wright
> Fix For: LCF Release 0.5
>
>
> (This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
> It has come to my attention that the API would be more "pure" RESTful if the API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the input argument identifier represented in the context path.
> So, GET outputconnection/get \{"connection_name":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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/<command>
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":<output_connection_object>} OR { } OR {"error":<error_text>}
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/<command> (connection_name, arguments) -> GET outputconnection/request/<command> (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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907724#action_12907724 ]
Karl Wright commented on CONNECTORS-98:
---------------------------------------
bq. http://en.wikipedia.org/wiki/Representational_State_Transfer
This reference says nothing of interest pertaining to the questions asked. It would seem that my proposal and yours both qualify as RESTful API's given this description.
bq. http://www.xfront.com/REST-Web-Services.html
This reference points out that REST is not a standard, it is a style. It establishes a goal of modeling all resources that you would manipulate or access with URLs. Thus, one needs to decide what the resource is, before one can decide what the url is. Unfortunately, it doesn't look to me like this reference's model is compatible with input arguments of any kind, except on PUT operations. That's going to mean a less flexible infrastructure to work with if we adopt this in strict form.
The other ramification is that all paths (which, after all, now must contain all the input arguments) must be url-encoded utf-8, as per the w3c standard.
My question is whether we really ought to go to the extreme of prohibiting input arguments for GET operations, as the second document would seem to recommend.
> API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
> -----------------------------------------------------------------------------------------------------
>
> Key: CONNECTORS-98
> URL: https://issues.apache.org/jira/browse/CONNECTORS-98
> Project: Apache Connectors Framework
> Issue Type: Improvement
> Components: API
> Affects Versions: LCF Release 0.5
> Reporter: Jack Krupansky
> Fix For: LCF Release 0.5
>
>
> (This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
> It has come to my attention that the API would be more "pure" RESTful if the API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the input argument identifier represented in the context path.
> So, GET outputconnection/get \{"connection_name":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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/<connection_name>/status ()
vs.
GET outputconnections/status/<connection_name> ()
Same for execute/request:
GET outputconnections/<connection_name>/request/<command> (arguments)
vs.
GET outputconnections/request/<connection_name>/<command> (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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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/<connection_name> ()
outputconnection/save (output_connection_object) -> PUT outputconnections (output_connection_object)
outputconnection/delete (connection_name) -> DELETE outputconnections/<connection_name> ()
outputconnection/list () -> GET outputconnections ()
outputconnection/checkstatus (connection_name) -> GET outputconnections/status/<connection_name> ()
outputconnection/execute/<command> (connection_name, arguments) -> GET outputconnections/request/<connection_name>/<command> (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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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/<connection_name> {"outputconnection":<output_connection_object>}
we could have:
PUT outputconnections {"outputconnection":<output_connection_object>}
Further, I don't think we need the extra level of object, so that could be:
PUT outputconnections {<output_connection_object>}
> API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
> -----------------------------------------------------------------------------------------------------
>
> Key: CONNECTORS-98
> URL: https://issues.apache.org/jira/browse/CONNECTORS-98
> Project: Apache Connectors Framework
> Issue Type: Improvement
> Components: API
> Affects Versions: LCF Release 0.5
> Reporter: Jack Krupansky
> Fix For: LCF Release 0.5
>
>
> (This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
> It has come to my attention that the API would be more "pure" RESTful if the API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the input argument identifier represented in the context path.
> So, GET outputconnection/get \{"connection_name":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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 ".<space>". So, either the client would have to write ".%2B" or we pick some other encoding. Lacking some more preferred choice, we could simply propose ".-" as our encoding for slash. Almost any (non-reserved) char will do.
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/<command>
(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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908573#action_12908573 ]
Jack Krupansky commented on CONNECTORS-98:
------------------------------------------
re: Spaces in connection names...
A URL path sent by a cleint cannot have an unencoded space. Typically, a space is encoded as "+" or "%20". The final path retrieved by the server app will have the expanded spaces, but the path to be sent via HTTP from the client must be encoded since a space is the delimiter between the path and the HTTP version as per IETF RFC 2616 Sec 5.1:
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
See:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html
The first upshot of this is that the client needs to encode spaces as "+" or "%20". Ditto for other reserved chars (described in an earlier comment.)
A second upshot of this is that we can't use ".+" in the original path from the client to encode slash since it would come through to the ACF server app as ".<space>". So, either the client would have to write ".%2B" or we pick some other encoding. Lacking some more preferred choice, we could simply propose ".-" as our encoding for slash. Almost any (non-reserved) char will do.
Another proposed encoding for slash: double the slash when it is to be embedded in a name and then the adjacent path segments will be merged with a single slash between. I don't like this since it is not encoding the full name as a single path segment, but it may be the cleanest way of dealing with slash. An example, encoding the name "this updated/revised example connection 1.0":
GET info/outputconnections/this+updated//revised+example+connection+1.0/<command>
Personally, I lean towards an encoding convention that can result in encoding the name as a single path segment. With the ".." and ".-" encoding convention this example would be:
GET info/outputconnections/this+updated.-revised+example+connection+1..0/<command>
> API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
> -----------------------------------------------------------------------------------------------------
>
> Key: CONNECTORS-98
> URL: https://issues.apache.org/jira/browse/CONNECTORS-98
> Project: Apache Connectors Framework
> Issue Type: Improvement
> Components: API
> Affects Versions: LCF Release 0.5
> Reporter: Jack Krupansky
> Fix For: LCF Release 0.5
>
>
> (This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
> It has come to my attention that the API would be more "pure" RESTful if the API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the input argument identifier represented in the context path.
> So, GET outputconnection/get \{"connection_name":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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/<command> (connection_name, arguments) -> GET outputconnections/request/<connection_name>/<command> (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/<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 outputconnectionstatus/<connection_name> ()
outputconnection/execute/<command> (connection_name, arguments) -> GET outputconnectionrequest/<connection_name>/<command> ()
> API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
> -----------------------------------------------------------------------------------------------------
>
> Key: CONNECTORS-98
> URL: https://issues.apache.org/jira/browse/CONNECTORS-98
> Project: Apache Connectors Framework
> Issue Type: Improvement
> Components: API
> Affects Versions: LCF Release 0.5
> Reporter: Jack Krupansky
> Fix For: LCF Release 0.5
>
>
> (This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
> It has come to my attention that the API would be more "pure" RESTful if the API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the input argument identifier represented in the context path.
> So, GET outputconnection/get \{"connection_name":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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/<command> (connection_name, arguments) -> GET outputconnectionrequest/<connection_name>/<command> ()
At issue is the <command> following the <connection_name>. These would need to be reversed:
outputconnection/execute/<command> (connection_name, arguments) -> GET request/<command>/outputconnection/<connection_name> ()
or:
outputconnection/execute/<command> (connection_name, arguments) -> GET request/outputconnection/<command>/<connection_name> ()
Problem is that for either one of these the <command> 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Mark Miller (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907942#action_12907942 ]
Karl Wright commented on CONNECTORS-98:
---------------------------------------
Actually, I realize that I *have* decided. Double-encoding will be too confusing. There is furthermore no reason not to put the connection name at the end of the url in all cases - in fact, it naturally works best that way, in my view. Your comment about not using slashes in names may not apply to end-users, who will be creating these names, but it certainly *does* apply to the one case I was worried about: creating connector-specific command names. So I think it's settled.
The final proposal, which I think is the only one that's going to work in all dimensions, is the following:
outputconnection/get (connection_name) -> GET outputconnection/<connection_name> ()
outputconnection/save (output_connection_object) -> PUT outputconnection (output_connection_object)
outputconnection/delete (connection_name) -> DELETE outputconnection/<connection_name> ()
outputconnection/list () -> GET outputconnections ()
outputconnection/checkstatus (connection_name) -> GET status/outputconnection/<connection_name> ()
outputconnection/execute/<command> (connection_name, arguments) -> GET info/<command>/outputconnection/<connection_name> ()
There will, of course, be similar "status" and "info" urls for all other connection types. The constant here is whenever you see "/outputconnection/" it is followed by the output connection name. That is why I did not suggest "list/outputconnection", because that breaks that consistency, but I could be convinced to do that instead of using the plural. I could have turned the whole thing around but then we would have either parsing conflicts or you'd need to add more to the url:
outputconnection/get (connection_name) -> GET outputconnection/instance/<connection_name> ()
... and I didn't think you'd like that.
This will, of course, set the style for all of the rest of the URLs too. I'll create the full proposal today, just to be sure there are no gotchas.
Note that the things we must GIVE UP for REST are:
(1) Arbitrarily complex JSON arguments to individual connector commands
(2) Commands with "/" in them, to individual connectors
> API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
> -----------------------------------------------------------------------------------------------------
>
> Key: CONNECTORS-98
> URL: https://issues.apache.org/jira/browse/CONNECTORS-98
> Project: Apache Connectors Framework
> Issue Type: Improvement
> Components: API
> Affects Versions: LCF Release 0.5
> Reporter: Jack Krupansky
> Fix For: LCF Release 0.5
>
>
> (This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
> It has come to my attention that the API would be more "pure" RESTful if the API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the input argument identifier represented in the context path.
> So, GET outputconnection/get \{"connection_name":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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/<connection_name> {"outputconnection":<output_connection_object>}
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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Jack Krupansky (JIRA)" <ji...@apache.org>.
[ 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 <command> 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with
the API verb represented using the HTTP GET/PUT/POST/DELETE methods
Posted by "Karl Wright (JIRA)" <ji...@apache.org>.
[ 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/<connection_name> ()
> API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
> -----------------------------------------------------------------------------------------------------
>
> Key: CONNECTORS-98
> URL: https://issues.apache.org/jira/browse/CONNECTORS-98
> Project: Apache Connectors Framework
> Issue Type: Improvement
> Components: API
> Affects Versions: LCF Release 0.5
> Reporter: Jack Krupansky
> Fix For: LCF Release 0.5
>
>
> (This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
> It has come to my attention that the API would be more "pure" RESTful if the API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the input argument identifier represented in the context path.
> So, GET outputconnection/get \{"connection_name":_<connection_name>_\} would be GET outputconnections/<connection_name>
> and GET outputconnection/delete \{"connection_name":_<connection_name>_\} would be DELETE outputconnections/<connection_name>
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save \{"outputconnection":_<output_connection_object>_\} would be PUT outputconnections/<connection_name> \{"outputconnection":_<output_connection_object>_\}
> What we have today is certainly workable, but just not as "pure" as some might desire. It would be better to take care of this before the initial release so that we never have to answer the question of why it wasn't done as a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can process the DELETE and PUT methods (using the doDelete and doPut method overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.