[jira] Commented: (CONNECTORS-98) API should be pure RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[ https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.
Re: [jira] Commented: (CONNECTORS-98) API should be pure RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
I briefly reviewed the proposal wiki and it looks good good enough to move forward. There may be revisions as we actually start using it, but this is definitely a big step in the right direction. -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Monday, September 13, 2010 4:30 AM To: connectors-dev@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) j...@apache.orgwrote: [ https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: [RESULT][VOTE] Pick your preferred name
ACF passed the Incubator vote. My question to the community is do you want me to go to the Board and ask for advice on this since the Board ultimately approves any podling graduating? One Director weighed in on the vote saying the Board wouldn't care, but in my view it was not an official opinion. I was actually thinking about asking the board for two things: 1. View of the name 2. Whether they have guidance on our repeated request about NTLM and it's inclusion in any ACF release. I believe someone was slated to engage with us a few months back, but I don't believe anyone has reached out to us yet. Thoughts? -Grant On Sep 7, 2010, at 4:54 AM, Karl Wright wrote: Voting is now closed. Final tally (which only counts Robert's first choice and not all three): Apache Connectors Framework 15 Apache Manifold 11 Apache Yukon 9 Apache Macon 4 Apache ManifoldCF 3 Apache Omni 1 Apache Acromantula 1 Apache Lukon 1 Karl -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
Re: [RESULT][VOTE] Pick your preferred name
On Mon, Sep 13, 2010 at 7:35 PM, Grant Ingersoll grant.ingers...@gmail.com wrote: ACF passed the Incubator vote. My question to the community is do you want me to go to the Board and ask for advice on this since the Board ultimately approves any podling graduating? One Director weighed in on the vote saying the Board wouldn't care, but in my view it was not an official opinion. I was actually thinking about asking the board for two things: 1. View of the name 2. Whether they have guidance on our repeated request about NTLM and it's inclusion in any ACF release. I believe someone was slated to engage with us a few months back, but I don't believe anyone has reached out to us yet. Thoughts? This whole name vote / discussion created lots of noise - we finally got to a decision and we should make sure it won't prevent us from graduation. Loosing a name during grad. process would be horrible IMO. +1 -Grant On Sep 7, 2010, at 4:54 AM, Karl Wright wrote: Voting is now closed. Final tally (which only counts Robert's first choice and not all three): Apache Connectors Framework 15 Apache Manifold 11 Apache Yukon 9 Apache Macon 4 Apache ManifoldCF 3 Apache Omni 1 Apache Acromantula 1 Apache Lukon 1 Karl -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
Re: [RESULT][VOTE] Pick your preferred name
+1 to both - review of name and address the NTLM issue since ACF is getting closer to where an actual 0.1 release could be considered. -- Jack Krupansky -- From: Grant Ingersoll grant.ingers...@gmail.com Sent: Monday, September 13, 2010 1:35 PM To: connectors-dev@incubator.apache.org Subject: Re: [RESULT][VOTE] Pick your preferred name ACF passed the Incubator vote. My question to the community is do you want me to go to the Board and ask for advice on this since the Board ultimately approves any podling graduating? One Director weighed in on the vote saying the Board wouldn't care, but in my view it was not an official opinion. I was actually thinking about asking the board for two things: 1. View of the name 2. Whether they have guidance on our repeated request about NTLM and it's inclusion in any ACF release. I believe someone was slated to engage with us a few months back, but I don't believe anyone has reached out to us yet. Thoughts? -Grant On Sep 7, 2010, at 4:54 AM, Karl Wright wrote: Voting is now closed. Final tally (which only counts Robert's first choice and not all three): Apache Connectors Framework 15 Apache Manifold 11 Apache Yukon 9 Apache Macon 4 Apache ManifoldCF 3 Apache Omni 1 Apache Acromantula 1 Apache Lukon 1 Karl -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
Re: [RESULT][VOTE] Pick your preferred name
+1 to both. Karl On Mon, Sep 13, 2010 at 2:22 PM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: +1 to both - review of name and address the NTLM issue since ACF is getting closer to where an actual 0.1 release could be considered. -- Jack Krupansky -- From: Grant Ingersoll grant.ingers...@gmail.com Sent: Monday, September 13, 2010 1:35 PM To: connectors-dev@incubator.apache.org Subject: Re: [RESULT][VOTE] Pick your preferred name ACF passed the Incubator vote. My question to the community is do you want me to go to the Board and ask for advice on this since the Board ultimately approves any podling graduating? One Director weighed in on the vote saying the Board wouldn't care, but in my view it was not an official opinion. I was actually thinking about asking the board for two things: 1. View of the name 2. Whether they have guidance on our repeated request about NTLM and it's inclusion in any ACF release. I believe someone was slated to engage with us a few months back, but I don't believe anyone has reached out to us yet. Thoughts? -Grant On Sep 7, 2010, at 4:54 AM, Karl Wright wrote: Voting is now closed. Final tally (which only counts Robert's first choice and not all three): Apache Connectors Framework 15 Apache Manifold 11 Apache Yukon 9 Apache Macon 4 Apache ManifoldCF 3 Apache Omni 1 Apache Acromantula 1 Apache Lukon 1 Karl -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
[jira] Assigned: (CONNECTORS-98) API should be pure RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[ https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels: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
[ https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.