Deleting records from ODK Aggregate via command line

Mark_Schormann1 · July 19, 2016, 9:47pm

I currently use the command line version of Briefcase to pull all the data
from Aggregate as CSV files. This allows for easy processing and various
other manipulations. However, once the processing is done, it would be
really great if the same script could circle back and clean up Aggregate.
In other words, what is needed is some additional functionality, within
Briefcase, given the same command line parameters as it currently uses to
refer to files/forms, to allow the deletion of records on Aggregate, given
the UUID.

Anybody had a look at this? Any ideas? Can it be done?

yanokwa · July 20, 2016, 11:11pm

Hi Mark,

It's a good idea, it can be done, and if you write the code, I'm sure
the core team would be glad to add it to Briefcase. Your alternative
is to hire a dev from http://opendatakit.org/help/help-for-hire or
file a feature request at https://github.com/opendatakit/opendatakit
and hope someone else does it (unlikely).

Yaw

···

-- Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Tue, Jul 19, 2016 at 2:47 PM, Mark Schormann schormannm@gmail.com wrote:

I currently use the command line version of Briefcase to pull all the data
from Aggregate as CSV files. This allows for easy processing and various
other manipulations. However, once the processing is done, it would be
really great if the same script could circle back and clean up Aggregate.
In other words, what is needed is some additional functionality, within
Briefcase, given the same command line parameters as it currently uses to
refer to files/forms, to allow the deletion of records on Aggregate, given
the UUID.

Anybody had a look at this? Any ideas? Can it be done?

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mark_Schormann · July 21, 2016, 10:14pm

Hi Yaw

Think I’ll take a look at the code and see what I can do.

Was hoping that perhaps someone had already had the idea, and solved it. In order to make things automated, it is virtually essential to have that step.

Regards
Mark

···

-----Original Message----- From: opendatakit-developers@googlegroups.com [mailto:opendatakit-developers@googlegroups.com] On Behalf Of Yaw Anokwa Sent: Thursday, 21 July 2016 1:11 AM To: ODK Developers Subject: Re: [ODK Developers] Deleting records from ODK Aggregate via command line

Hi Mark,

It's a good idea, it can be done, and if you write the code, I'm sure the core team would be glad to add it to Briefcase. Your alternative is to hire a dev from http://opendatakit.org/help/help-for-hire or file a feature request at https://github.com/opendatakit/opendatakit
and hope someone else does it (unlikely).

Yaw

Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Tue, Jul 19, 2016 at 2:47 PM, Mark Schormann schormannm@gmail.com wrote:

I currently use the command line version of Briefcase to pull all the
data from Aggregate as CSV files. This allows for easy processing and
various other manipulations. However, once the processing is done, it
would be really great if the same script could circle back and clean up Aggregate.
In other words, what is needed is some additional functionality,
within Briefcase, given the same command line parameters as it
currently uses to refer to files/forms, to allow the deletion of
records on Aggregate, given the UUID.

Anybody had a look at this? Any ideas? Can it be done?

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/opendatakit-developers/apE33LMmWZI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

yanokwa · July 22, 2016, 2:05pm

Mark,

And if it is essential for you, that's a great opportunity to build
and contribute that functionality back to the community.

Yaw

···

-- Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Thu, Jul 21, 2016 at 3:14 PM, Mark Schormann mark@soft.co.za wrote:

Hi Yaw

Think I’ll take a look at the code and see what I can do.

Was hoping that perhaps someone had already had the idea, and solved it. In order to make things automated, it is virtually essential to have that step.

Regards
Mark

-----Original Message-----
From: opendatakit-developers@googlegroups.com [mailto:opendatakit-developers@googlegroups.com] On Behalf Of Yaw Anokwa
Sent: Thursday, 21 July 2016 1:11 AM
To: ODK Developers opendatakit-developers@googlegroups.com
Subject: Re: [ODK Developers] Deleting records from ODK Aggregate via command line

Hi Mark,

It's a good idea, it can be done, and if you write the code, I'm sure the core team would be glad to add it to Briefcase. Your alternative is to hire a dev from http://opendatakit.org/help/help-for-hire or file a feature request at https://github.com/opendatakit/opendatakit
and hope someone else does it (unlikely).

Yaw

Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Tue, Jul 19, 2016 at 2:47 PM, Mark Schormann schormannm@gmail.com wrote:

I currently use the command line version of Briefcase to pull all the
data from Aggregate as CSV files. This allows for easy processing and
various other manipulations. However, once the processing is done, it
would be really great if the same script could circle back and clean up Aggregate.
In other words, what is needed is some additional functionality,
within Briefcase, given the same command line parameters as it
currently uses to refer to files/forms, to allow the deletion of
records on Aggregate, given the UUID.

Anybody had a look at this? Any ideas? Can it be done?

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/opendatakit-developers/apE33LMmWZI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mark_Schormann · July 24, 2016, 12:29pm

Yaw,

Anybody able to contribute some direction on this? I don't mind doing some work on it, but find the prospect daunting. Specifically, which source files might be involved and what the approach might be that fits in with the historical thinking on the matter.

Having looked through the body of source files in Briefcase, my feeling would be that I could confine my approach to the command line section of the program. The idea would then be to add an extra command line parameter for deletion of a specific record on Aggregate, with the parameter supplied being the UUID of the submission.

However, this then implies that there needs to be modification of Aggregate as well, to accommodate this functionality. I don't even know where to start on that. However, some specific issues come to mind. In particular, to delete a specific record on Aggregate, I suspect one needs more than just the UUID of the submission. Perhaps I am wrong.

Anyway, any insights and input would be welcomed. Or some assistance from someone better qualified?

Regards
Mark

···

-----Original Message----- From: opendatakit-developers@googlegroups.com [mailto:opendatakit-developers@googlegroups.com] On Behalf Of Yaw Anokwa Sent: Friday, 22 July 2016 4:05 PM To: ODK Developers Subject: Re: [ODK Developers] Deleting records from ODK Aggregate via command line

Mark,

And if it is essential for you, that's a great opportunity to build and contribute that functionality back to the community.

Yaw

Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Thu, Jul 21, 2016 at 3:14 PM, Mark Schormann mark@soft.co.za wrote:

Hi Yaw

Think I’ll take a look at the code and see what I can do.

Was hoping that perhaps someone had already had the idea, and solved it. In order to make things automated, it is virtually essential to have that step.

Regards
Mark

-----Original Message-----
From: opendatakit-developers@googlegroups.com
[mailto:opendatakit-developers@googlegroups.com] On Behalf Of Yaw
Anokwa
Sent: Thursday, 21 July 2016 1:11 AM
To: ODK Developers opendatakit-developers@googlegroups.com
Subject: Re: [ODK Developers] Deleting records from ODK Aggregate via
command line

Hi Mark,

It's a good idea, it can be done, and if you write the code, I'm sure
the core team would be glad to add it to Briefcase. Your alternative
is to hire a dev from http://opendatakit.org/help/help-for-hire or
file a feature request at https://github.com/opendatakit/opendatakit
and hope someone else does it (unlikely).

Yaw

Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Tue, Jul 19, 2016 at 2:47 PM, Mark Schormann schormannm@gmail.com wrote:

I currently use the command line version of Briefcase to pull all the
data from Aggregate as CSV files. This allows for easy processing
and various other manipulations. However, once the processing is
done, it would be really great if the same script could circle back and clean up Aggregate.
In other words, what is needed is some additional functionality,
within Briefcase, given the same command line parameters as it
currently uses to refer to files/forms, to allow the deletion of
records on Aggregate, given the UUID.

Anybody had a look at this? Any ideas? Can it be done?

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/opendatakit-developers/apE33LMmWZI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/opendatakit-developers/apE33LMmWZI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mitch_S · August 9, 2016, 12:14am

Documentation on the structure of ODK Aggregate code is on the developer
wiki:

https://github.com/opendatakit/opendatakit/wiki

e.g.,
https://github.com/opendatakit/opendatakit/wiki/Aggregate-Source-Code-Overview

and https://github.com/opendatakit/opendatakit/wiki/Briefcase-Aggregate-API

See the CONFIGURE.txt in the root of the aggregate GitHub project for how
to configure your Eclipse development environment.
Note that you MUST use Java 7. Create your own clone branch based off of
the 'uiexperiment' branch (the active development tip).

The functionality would be implemented as a servlet.

The servlet to download an individual submission is here:

github.com

getodk/aggregate/blob/master/src/main/java/org/opendatakit/aggregate/servlet/SubmissionDownloadServlet.java

/*
 * Copyright (C) 2011 University of Washington.
 *
 * Licensed under the Apache License, Version 2.0 (the "License"); you may not
 * use this file except in compliance with the License. You may obtain a copy of
 * the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
 * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
 * License for the specific language governing permissions and limitations under
 * the License.
 */

package org.opendatakit.aggregate.servlet;

import java.io.IOException;
import java.io.PrintWriter;

This file has been truncated. show original

In this case, you would want to replicate that but implement only a
doDelete() method and delete the submission. The deletion of the submission
can use:

github.com

getodk/aggregate/blob/master/src/main/java/org/opendatakit/aggregate/process/DeleteSubmissions.java

/*
 * Copyright (C) 2010 University of Washington
 *
 * Licensed under the Apache License, Version 2.0 (the "License"); you may not
 * use this file except in compliance with the License. You may obtain a copy of
 * the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
 * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
 * License for the specific language governing permissions and limitations under
 * the License.
 */

package org.opendatakit.aggregate.process;

import java.util.ArrayList;
import java.util.List;

This file has been truncated. show original

The servlet needs to be declared in the web.xml and in the
applicationContext-security.xml files here:

https://github.com/opendatakit/aggregate/tree/master/war-base/WEB-INF

The access restriction for the servlet (in applicationContext-security.xml)
should be ROLE_DATA_OWNER (restricting the ability to delete rows to those
users with Forms Manager privileges.

···

On Sun, Jul 24, 2016 at 5:29 AM, Mark Schormann wrote:

Yaw,

Anybody able to contribute some direction on this? I don't mind doing
some work on it, but find the prospect daunting. Specifically, which
source files might be involved and what the approach might be that fits in
with the historical thinking on the matter.

Having looked through the body of source files in Briefcase, my feeling
would be that I could confine my approach to the command line section of
the program. The idea would then be to add an extra command line parameter
for deletion of a specific record on Aggregate, with the parameter supplied
being the UUID of the submission.

However, this then implies that there needs to be modification of
Aggregate as well, to accommodate this functionality. I don't even know
where to start on that. However, some specific issues come to mind. In
particular, to delete a specific record on Aggregate, I suspect one needs
more than just the UUID of the submission. Perhaps I am wrong.

Anyway, any insights and input would be welcomed. Or some assistance
from someone better qualified?

Regards
Mark

-----Original Message-----
From: opendatakit-developers@googlegroups.com [mailto:opendatakit-
developers@googlegroups.com] On Behalf Of Yaw Anokwa
Sent: Friday, 22 July 2016 4:05 PM
To: ODK Developers opendatakit-developers@googlegroups.com
Subject: Re: [ODK Developers] Deleting records from ODK Aggregate via
command line

Mark,

And if it is essential for you, that's a great opportunity to build and
contribute that functionality back to the community.

Yaw

Need ODK consultants? Nafundi provides form design, server setup, in-field
training, and software development for ODK. Go to https://nafundi.com to
get started.

On Thu, Jul 21, 2016 at 3:14 PM, Mark Schormann mark@soft.co.za wrote:

Hi Yaw

Think I’ll take a look at the code and see what I can do.

Was hoping that perhaps someone had already had the idea, and solved
it. In order to make things automated, it is virtually essential to have
that step.

Regards
Mark

-----Original Message-----
From: opendatakit-developers@googlegroups.com
[mailto:opendatakit-developers@googlegroups.com] On Behalf Of Yaw
Anokwa
Sent: Thursday, 21 July 2016 1:11 AM
To: ODK Developers opendatakit-developers@googlegroups.com
Subject: Re: [ODK Developers] Deleting records from ODK Aggregate via
command line

Hi Mark,

It's a good idea, it can be done, and if you write the code, I'm sure
the core team would be glad to add it to Briefcase. Your alternative
is to hire a dev from http://opendatakit.org/help/help-for-hire or
file a feature request at https://github.com/opendatakit/opendatakit
and hope someone else does it (unlikely).

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Tue, Jul 19, 2016 at 2:47 PM, Mark Schormann schormannm@gmail.com wrote:

I currently use the command line version of Briefcase to pull all the
data from Aggregate as CSV files. This allows for easy processing
and various other manipulations. However, once the processing is
done, it would be really great if the same script could circle back and
clean up Aggregate.
In other words, what is needed is some additional functionality,
within Briefcase, given the same command line parameters as it
currently uses to refer to files/forms, to allow the deletion of
records on Aggregate, given the UUID.

Anybody had a look at this? Any ideas? Can it be done?

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/opendatakit-developers/apE33LMmWZI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/opendatakit-developers/apE33LMmWZI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Frank_Dekervel · April 25, 2017, 8:16pm

Hello,

I have the same needs here, and i'm trying to follow your instructions to implement. I do have some questions wrt API design best practises.

Would a deleteSubmission servlet have the same parameters as a downloadSubmission request ? eg a GET with a submissionkey ? this means one API call per submission (eg no efficient mass-deletion), which is fine for me. Wouldn't a POST request be better ?

And i would place the webservice not under '/view' but directly under /

// verify parameters are present
String keyString = getParameter(req, ServletConsts.FORM_ID);
if (keyString == null) {
  sendErrorNotEnoughParams(resp);
  return;
}
SubmissionKey key = new SubmissionKey(keyString);

List<SubmissionKey> kl = new LinkedList<SubmissionKey>();
kl.add(key);


// https://groups.google.com/forum/#!topic/opendatakit-developers/apE33LMmWZI
DeleteSubmissions ds = new DeleteSubmissions(kl);
try {
  ds.deleteSubmissions(cc);
  resp.setCharacterEncoding(HtmlConsts.UTF8_ENCODE);
  resp.setContentType(HtmlConsts.RESP_TYPE_PLAIN);
  addOpenRosaHeaders(resp);
  PrintWriter out = resp.getWriter();
  out.write("okay");

} catch (ODKFormNotFoundException e) {
  odkIdNotFoundError(resp);
  errorRetreivingData(resp);
} catch (ODKDatastoreException e) {
  e.printStackTrace();
  errorRetreivingData(resp);
}

Greetings,
Frank

···

Op dinsdag 9 augustus 2016 02:14:39 UTC+2 schreef Mitch: > Documentation on the structure of ODK Aggregate code is on the developer wiki: > > > https://github.com/opendatakit/opendatakit/wiki > > > > e.g., https://github.com/opendatakit/opendatakit/wiki/Aggregate-Source-Code-Overview > > > and https://github.com/opendatakit/opendatakit/wiki/Briefcase-Aggregate-API > > > See the CONFIGURE.txt in the root of the aggregate GitHub project for how to configure your Eclipse development environment. > Note that you MUST use Java 7. Create your own clone branch based off of the 'uiexperiment' branch (the active development tip). > > > The functionality would be implemented as a servlet. > > > https://github.com/opendatakit/aggregate/tree/master/src/main/java/org/opendatakit/aggregate/servlet > > > > The servlet to download an individual submission is here: > > > https://github.com/opendatakit/aggregate/blob/master/src/main/java/org/opendatakit/aggregate/servlet/SubmissionDownloadServlet.java > > > > In this case, you would want to replicate that but implement only a doDelete() method and delete the submission. The deletion of the submission can use: > > > https://github.com/opendatakit/aggregate/blob/master/src/main/java/org/opendatakit/aggregate/process/DeleteSubmissions.java > > > > The servlet needs to be declared in the web.xml and in the applicationContext-security.xml files here: > > > https://github.com/opendatakit/aggregate/tree/master/war-base/WEB-INF > > > > The access restriction for the servlet (in applicationContext-security.xml) should be ROLE_DATA_OWNER (restricting the ability to delete rows to those users with Forms Manager privileges. > > > > > > > On Sun, Jul 24, 2016 at 5:29 AM, Mark Schormann wrote: > Yaw, > > > > Anybody able to contribute some direction on this? I don't mind doing some work on it, but find the prospect daunting. Specifically, which source files might be involved and what the approach might be that fits in with the historical thinking on the matter. > > > > Having looked through the body of source files in Briefcase, my feeling would be that I could confine my approach to the command line section of the program. The idea would then be to add an extra command line parameter for deletion of a specific record on Aggregate, with the parameter supplied being the UUID of the submission. > > > > However, this then implies that there needs to be modification of Aggregate as well, to accommodate this functionality. I don't even know where to start on that. However, some specific issues come to mind. In particular, to delete a specific record on Aggregate, I suspect one needs more than just the UUID of the submission. Perhaps I am wrong. > > > > Anyway, any insights and input would be welcomed. Or some assistance from someone better qualified? > > > > Regards > > Mark > > > > -----Original Message----- > > From: opendatakit...@googlegroups.com [mailto:opendatakit-developers@googlegroups.com] On Behalf Of Yaw Anokwa > > > > Sent: Friday, 22 July 2016 4:05 PM > > To: ODK Developers > > Subject: Re: [ODK Developers] Deleting records from ODK Aggregate via command line > > > > Mark, > > > > And if it is essential for you, that's a great opportunity to build and contribute that functionality back to the community. > > > > Yaw > > -- > > Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started. > > > > On Thu, Jul 21, 2016 at 3:14 PM, Mark Schormann wrote: > > > Hi Yaw > > > > > > Think I’ll take a look at the code and see what I can do. > > > > > > Was hoping that perhaps someone had already had the idea, and solved it. In order to make things automated, it is virtually essential to have that step. > > > > > > Regards > > > Mark > > > > > > -----Original Message----- > > > From: opendatakit...@googlegroups.com > > > [mailto:opendatakit-developers@googlegroups.com] On Behalf Of Yaw > > > Anokwa > > > Sent: Thursday, 21 July 2016 1:11 AM > > > To: ODK Developers > > > Subject: Re: [ODK Developers] Deleting records from ODK Aggregate via > > > command line > > > > > > Hi Mark, > > > > > > It's a good idea, it can be done, and if you write the code, I'm sure > > > the core team would be glad to add it to Briefcase. Your alternative > > > is to hire a dev from http://opendatakit.org/help/help-for-hire or > > > file a feature request at https://github.com/opendatakit/opendatakit > > > and hope someone else does it (unlikely). > > > > > > Yaw > > > -- > > > Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started. > > > > > > On Tue, Jul 19, 2016 at 2:47 PM, Mark Schormann wrote: > > >> I currently use the command line version of Briefcase to pull all the > > >> data from Aggregate as CSV files. This allows for easy processing > > >> and various other manipulations. However, once the processing is > > >> done, it would be really great if the same script could circle back and clean up Aggregate. > > >> In other words, what is needed is some additional functionality, > > >> within Briefcase, given the same command line parameters as it > > >> currently uses to refer to files/forms, to allow the deletion of > > >> records on Aggregate, given the UUID. > > >> > > >> Anybody had a look at this? Any ideas? Can it be done? > > >> > > >> -- > > >> You received this message because you are subscribed to the Google > > >> Groups "ODK Developers" group. > > >> To unsubscribe from this group and stop receiving emails from it, > > >> send an email to opendatakit-developers+unsubscribe@googlegroups.com. > > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > > You received this message because you are subscribed to a topic in the Google Groups "ODK Developers" group. > > > To unsubscribe from this topic, visit https://groups.google.com/d/topic/opendatakit-developers/apE33LMmWZI/unsubscribe. > > > To unsubscribe from this group and all its topics, send an email to opendatakit-developers+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > > You received this message because you are subscribed to the Google Groups "ODK Developers" group. > > > To unsubscribe from this group and stop receiving emails from it, send an email to opendatakit-developers+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to a topic in the Google Groups "ODK Developers" group. > > To unsubscribe from this topic, visit https://groups.google.com/d/topic/opendatakit-developers/apE33LMmWZI/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to opendatakit-developers+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google Groups "ODK Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to opendatakit-developers+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com

Xiphware · April 27, 2017, 8:46pm

In keeping with the format for the existing downloadSubmission, I might suggest something like:

HTTP DELETE http://opendatakit.appspot.com:8080/deleteSubmission?formId=sampleform[@version=null%20and%20@uiVersion=null]/data[@key=uuid:666a6993-8df9-44b5-90bf-58f5eff121d5]

and since uiVersion is optional on download, ditto

HTTP DELETE http://opendatakit.appspot.com:8080/deleteSubmission?formId=sampleform[@version=null%20]/data[@key=uuid:666a6993-8df9-44b5-90bf-58f5eff121d5]

An HTTP DELETE is probably most strictly appropriate, since we're deleting a resource. But otherwise a PUT is probably good enough, since you could argue we're 'updating the resource' (by changing its status to "Unavailable"...). GET isn't really appropriate, since the expectation of GET is that, when successful, you are return a resource which we're not in this case. POST is wholly inappropriate.

Given ODKAggregate doesn't currently support batch download of submissions, a batch delete is a bit premature IMO. But both are certainly reasonable requests [see below...]

I do believe that all the basic form lifecycle management function that you can currently do via the web interface should also be exposed via an appropriate API: delete submissions, delete forms, publish, export, etc. All this functionality is already in ODK Aggregate, so really the hard work is sitting down and standardizing the API. Anyone (else) interested in helping do this?

Gareth

···

On Wednesday, April 26, 2017 at 8:29:01 AM UTC+12, ker...@gmail.com wrote: > Hello, > > I have the same needs here, and i'm trying to follow your instructions to implement. I do have some questions wrt API design best practises. > > Would a deleteSubmission servlet have the same parameters as a downloadSubmission request ? eg a GET with a submissionkey ? this means one API call per submission (eg no efficient mass-deletion), which is fine for me. Wouldn't a POST request be better ? > > And i would place the webservice not under '/view' but directly under /

Xiphware · April 27, 2017, 8:53pm

Oh, and I dont really understand why submission (of 1 record) is under /, but downloadSubmission (of 1 record) is under /view/. There may be historical reasons for this (?), but its probably something else to consider normalizing in the API, especially if we're going to expose more APIs.

Xiphware · April 29, 2017, 12:54am

Hello,

I have the same needs here, and i'm trying to follow your instructions
to implement. I do have some questions wrt API design best practises.

Would a deleteSubmission servlet have the same parameters as a
downloadSubmission request ? eg a GET with a submissionkey ? this means one
API call per submission (eg no efficient mass-deletion), which is fine for
me. Wouldn't a POST request be better ?

And i would place the webservice not under '/view' but directly under /

In keeping with the format for the existing downloadSubmission, I might
suggest something like:

HTTP DELETE
http://opendatakit.appspot.com:8080/deleteSubmission?formId=sampleform[@version=null%20and%20@uiVersion=null]/data[@key=uuid:666a6993-8df9-44b5-90bf-58f5eff121d5]

and since uiVersion is optional on download, ditto

HTTP DELETE
http://opendatakit.appspot.com:8080/deleteSubmission?formId=sampleform[@version=null%20]/data[@key=uuid:666a6993-8df9-44b5-90bf-58f5eff121d5]

An HTTP DELETE is probably most strictly appropriate, since we're deleting
a resource. But otherwise a PUT is probably good enough, since you could
argue we're 'updating the resource' (by changing its status to
"Unavailable"...). GET isn't really appropriate, since the expectation of
GET is that, when successful, you are return a resource which we're not in
this case. POST is wholly inappropriate.

To be clear, I said "POST is wholly inappropriate" under the assumption
that ODK Aggregate - or more precisely OpenRosa 1.0 - prerequisites
HTTP1.1. But after searching thru the spec (here
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaAPI) I dont see that
HTTP1.1 is strictly required [although there are several mentions of 1.1
being needed for certain 'optional' functions. For example AUTH-API:]

Servers which implement the AUTH-API should follow the specifications

provided below in order to be compliant with OpenRosa standards.

all http interactions MUST be HTTP 1.1 ...

If ODK Aggregate is only going to prereg HTTP 1.0 then POST is probably
most appropriate method for delete, only because the only other option (in
1.0) is GET, and which is even worse But if HTTP 1.1 is (or will?)
strictly be required, then I think - regardless of REST plans - using HTTP
1.1 DELETE (or PUT) since deleting a submission record is precisely the
sorta operation for which it was defined. In the HTTP 1.1 space, POST is
formally defined in RFC2616
https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html for:

The POST method is used to request that the origin server accept the entity

enclosed in the request as a new subordinate of the resource identified by
the Request-URI in the Request-Line. POST is designed to allow a uniform
method to cover the following functions:
  - Annotation of existing resources;

  - Posting a message to a bulletin board, newsgroup, mailing list,
    or similar group of articles;

  - Providing a block of data, such as the result of submitting a
    form, to a data-handling process;

  - Extending a database through an append operation.

Ultimately, however ODK Aggregate decides to go about supporting delete, I
dont think the API should be defined in-house, rather it seems to make the
most sense to extend the OpenRosa specification to encompass deleting
submssions (and deleting forms too? since the current API supports creating
them...). That is to say, the final decision lies with the JavaRosa API
committee: Yaw, Mitch, et al.

Gareth

···

On Friday, April 28, 2017 at 8:46:17 AM UTC+12, xiph...@gmail.com wrote: > On Wednesday, April 26, 2017 at 8:29:01 AM UTC+12, ker...@gmail.com wrote:

Frank_Dekervel · April 28, 2017, 8:05am

Hello,

Thanks for your reply!
I think the reason for /view is that there is a special security role
associated to everything under /view (right ?)

For which HTTP method to use:

HTTP GET is out of the question as it would be a security issue (eg i
could trigger a delete on your system by sending you an IMG SRC="
http://opendatakit.appspot.com:8080/deleteSubmission..."/)
HTTP DELETE would be logical for a restful api (in which every
submission had its own url), but the aggregate api is "old style" not rest.
HTTP PUT is for updating a certain url in restful semantics, and here
we don't really update the "deleteSubmission" url.

i would hence think HTTP POST would be most appropriate for an "old style
api". agree ?

That being said, i would like a RESTful API for forms and form submissions,
but that's a bigger undertaking ...

My aggregate branch containing the deletesubmission API is here now:

https://github.com/Kapernikov/aggregate/tree/deletesubmission_api

Greetings,
Frank

···

On Thu, Apr 27, 2017 at 10:53 PM, wrote:

Oh, and I dont really understand why submission (of 1 record) is under /,
but downloadSubmission (of 1 record) is under /view/. There may be
historical reasons for this (?), but its probably something else to
consider normalizing in the API, especially if we're going to expose more
APIs.

yanokwa · May 3, 2017, 6:06pm

I think the lack of a RESTful API in Aggregate is a big painpoint for
building integrations, and to be honest, I don't know the best
approach is to get us there.

A decent first pass is probably to see what Enketo
(https://apidocs.enketo.org/v2) and Ona
(https://ona.io/static/docs/index.html) implement first. Then see how
that fits into OpenROSA's API so we can put together a rough proposal
for the community to discuss.

Frank/Gareth: Any interest in taking the lead on this? I want to get
to a point where folks don't have to have forks of Aggregate just to
get a reasonable API.

Yaw

···

On Fri, Apr 28, 2017 at 3:05 AM, Frank Dekervel wrote: > Hello, > > Thanks for your reply! > I think the reason for /view is that there is a special security role > associated to everything under /view (right ?) > > For which HTTP method to use: > > HTTP GET is out of the question as it would be a security issue (eg i could > trigger a delete on your system by sending you an IMG > SRC="http://opendatakit.appspot.com:8080/deleteSubmission..."/) > HTTP DELETE would be logical for a restful api (in which every submission > had its own url), but the aggregate api is "old style" not rest. > HTTP PUT is for updating a certain url in restful semantics, and here we > don't really update the "deleteSubmission" url. > > i would hence think HTTP POST would be most appropriate for an "old style > api". agree ? > > That being said, i would like a RESTful API for forms and form submissions, > but that's a bigger undertaking ... > > My aggregate branch containing the deletesubmission API is here now: > > https://github.com/Kapernikov/aggregate/tree/deletesubmission_api > > Greetings, > Frank > > > > On Thu, Apr 27, 2017 at 10:53 PM, wrote: >> >> Oh, and I dont really understand why submission (of 1 record) is under /, >> but downloadSubmission (of 1 record) is under /view/. There may be >> historical reasons for this (?), but its probably something else to consider >> normalizing in the API, especially if we're going to expose more APIs. > > > -- > You received this message because you are subscribed to the Google Groups > "ODK Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to opendatakit-developers+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.

wonderchook · May 3, 2017, 10:00pm

I would be interested in assisting with outlining a RESTful API. It has
certainly been a pain point for me in the past. I'm not that familiar with
Aggregate so I don't think I'd be a good lead, but I can certainly support.

-Kate

[image: Cadasta Logo] [image: Grey Divider] Kate Chapman
Chief Technology Officer
703.673.8834 | Cadasta.org http://cadasta.org/
https://twitter.com/CadastaOrg https://www.facebook.com/CadastaOrg/
https://www.linkedin.com/company/6417003

···

On Wed, May 3, 2017 at 11:06 AM, Yaw Anokwa wrote:

I think the lack of a RESTful API in Aggregate is a big painpoint for
building integrations, and to be honest, I don't know the best
approach is to get us there.

A decent first pass is probably to see what Enketo
(https://apidocs.enketo.org/v2) and Ona
(https://ona.io/static/docs/index.html) implement first. Then see how
that fits into OpenROSA's API so we can put together a rough proposal
for the community to discuss.

Frank/Gareth: Any interest in taking the lead on this? I want to get
to a point where folks don't have to have forks of Aggregate just to
get a reasonable API.

Yaw

On Fri, Apr 28, 2017 at 3:05 AM, Frank Dekervel kervel@gmail.com wrote:

Hello,

Thanks for your reply!
I think the reason for /view is that there is a special security role
associated to everything under /view (right ?)

For which HTTP method to use:

HTTP GET is out of the question as it would be a security issue (eg i
could
trigger a delete on your system by sending you an IMG
SRC="http://opendatakit.appspot.com:8080/deleteSubmission..."/)
HTTP DELETE would be logical for a restful api (in which every submission
had its own url), but the aggregate api is "old style" not rest.
HTTP PUT is for updating a certain url in restful semantics, and here we
don't really update the "deleteSubmission" url.

i would hence think HTTP POST would be most appropriate for an "old style
api". agree ?

That being said, i would like a RESTful API for forms and form
submissions,
but that's a bigger undertaking ...

My aggregate branch containing the deletesubmission API is here now:

https://github.com/Kapernikov/aggregate/tree/deletesubmission_api

Greetings,
Frank

On Thu, Apr 27, 2017 at 10:53 PM, xiphware@gmail.com wrote:

Oh, and I dont really understand why submission (of 1 record) is under
/,
but downloadSubmission (of 1 record) is under /view/. There may be
historical reasons for this (?), but its probably something else to
consider
normalizing in the API, especially if we're going to expose more APIs.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mark_Schormann · May 3, 2017, 11:47pm

Similar to Kate, I would be interested in being involved in a support role. I would really like to see the implementation of a RESTful API for Aggregate. It has certainly been a pain point, as others have said.

Regards

Mark

···

From: opendatakit-developers@googlegroups.com [mailto:opendatakit-developers@googlegroups.com] On Behalf Of Kate Chapman Sent: Thursday, 04 May 2017 12:01 AM To: opendatakit-developers@googlegroups.com Cc: xiphware@gmail.com Subject: Re: [ODK Developers] Deleting records from ODK Aggregate via command line

I would be interested in assisting with outlining a RESTful API. It has certainly been a pain point for me in the past. I'm not that familiar with Aggregate so I don't think I'd be a good lead, but I can certainly support.

-Kate

http://cadasta.org/wp-content/uploads/2016/11/logo.png

http://cadasta.org/wp-content/uploads/2016/11/grey.png

Kate Chapman
Chief Technology Officer
tel:703.673.8834 703.673.8834 | http://cadasta.org/ Cadasta.org

https://twitter.com/CadastaOrg

https://www.facebook.com/CadastaOrg/

https://www.linkedin.com/company/6417003

On Wed, May 3, 2017 at 11:06 AM, Yaw Anokwa <yanokwa@nafundi.com mailto:yanokwa@nafundi.com > wrote:

I think the lack of a RESTful API in Aggregate is a big painpoint for
building integrations, and to be honest, I don't know the best
approach is to get us there.

A decent first pass is probably to see what Enketo
(https://apidocs.enketo.org/v2) and Ona
(https://ona.io/static/docs/index.html) implement first. Then see how
that fits into OpenROSA's API so we can put together a rough proposal
for the community to discuss.

Frank/Gareth: Any interest in taking the lead on this? I want to get
to a point where folks don't have to have forks of Aggregate just to
get a reasonable API.

Yaw

On Fri, Apr 28, 2017 at 3:05 AM, Frank Dekervel <kervel@gmail.com mailto:kervel@gmail.com > wrote:

Hello,

Thanks for your reply!
I think the reason for /view is that there is a special security role
associated to everything under /view (right ?)

For which HTTP method to use:

HTTP GET is out of the question as it would be a security issue (eg i could
trigger a delete on your system by sending you an IMG
SRC="http://opendatakit.appspot.com:8080/deleteSubmission..."/)
HTTP DELETE would be logical for a restful api (in which every submission
had its own url), but the aggregate api is "old style" not rest.
HTTP PUT is for updating a certain url in restful semantics, and here we
don't really update the "deleteSubmission" url.

i would hence think HTTP POST would be most appropriate for an "old style
api". agree ?

That being said, i would like a RESTful API for forms and form submissions,
but that's a bigger undertaking ...

My aggregate branch containing the deletesubmission API is here now:

https://github.com/Kapernikov/aggregate/tree/deletesubmission_api

Greetings,
Frank

On Thu, Apr 27, 2017 at 10:53 PM, <xiphware@gmail.com mailto:xiphware@gmail.com > wrote:

Oh, and I dont really understand why submission (of 1 record) is under /,
but downloadSubmission (of 1 record) is under /view/. There may be
historical reasons for this (?), but its probably something else to consider
normalizing in the API, especially if we're going to expose more APIs.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com mailto:opendatakit-developers%2Bunsubscribe@googlegroups.com .
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opendatakit-developers+unsubscribe@googlegroups.com mailto:opendatakit-developers%2Bunsubscribe@googlegroups.com .
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/opendatakit-developers/apE33LMmWZI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to opendatakit-developers+unsubscribe@googlegroups.com mailto:opendatakit-developers+unsubscribe@googlegroups.com .
For more options, visit https://groups.google.com/d/optout.

Matthew_White · May 16, 2017, 9:45pm

Hi all,

I'm also interested in a REST API for Aggregate, and I've worked with Yaw
and Hélène to create a brainstorming document. Feel free to add your use
cases and any other thoughts, or comment on others'. With a better sense of
the desired functionality, the community can start prioritizing and
figuring out implementation strategies.

I'll go ahead and give everyone in this thread write access. However,
anyone should feel free to request write access.

Matt

···

On Wednesday, May 3, 2017 at 7:47:34 PM UTC-4, Mark Schormann wrote: > > Similar to Kate, I would be interested in being involved in a support > role. I would really like to see the implementation of a RESTful API for > Aggregate. It has certainly been a pain point, as others have said. > > > > Regards > > Mark > > > > *From:* opendatakit...@googlegroups.com [mailto: > opendatakit-developers@googlegroups.com ] *On Behalf Of *Kate > Chapman > *Sent:* Thursday, 04 May 2017 12:01 AM > *To:* opendatakit...@googlegroups.com > *Cc:* xiph...@gmail.com > *Subject:* Re: [ODK Developers] Deleting records from ODK Aggregate via > command line > > > > I would be interested in assisting with outlining a RESTful API. It has > certainly been a pain point for me in the past. I'm not that familiar with > Aggregate so I don't think I'd be a good lead, but I can certainly support. > > > > -Kate > > > [image: Cadasta Logo] > > [image: Grey Divider] > > *Kate Chapman* > *Chief Technology Officer* > 703.673.8834 | Cadasta.org > > > > > > > > > > On Wed, May 3, 2017 at 11:06 AM, Yaw Anokwa <yan...@nafundi.com > wrote: > > I think the lack of a RESTful API in Aggregate is a big painpoint for > building integrations, and to be honest, I don't know the best > approach is to get us there. > > A decent first pass is probably to see what Enketo > (https://apidocs.enketo.org/v2) and Ona > (https://ona.io/static/docs/index.html) implement first. Then see how > that fits into OpenROSA's API so we can put together a rough proposal > for the community to discuss. > > Frank/Gareth: Any interest in taking the lead on this? I want to get > to a point where folks don't have to have forks of Aggregate just to > get a reasonable API. > > Yaw > > > On Fri, Apr 28, 2017 at 3:05 AM, Frank Dekervel <ker...@gmail.com > wrote: > > Hello, > > > > Thanks for your reply! > > I think the reason for /view is that there is a special security role > > associated to everything under /view (right ?) > > > > For which HTTP method to use: > > > > HTTP GET is out of the question as it would be a security issue (eg i > could > > trigger a delete on your system by sending you an IMG > > SRC="http://opendatakit.appspot.com:8080/deleteSubmission..."/) > > HTTP DELETE would be logical for a restful api (in which every submission > > had its own url), but the aggregate api is "old style" not rest. > > HTTP PUT is for updating a certain url in restful semantics, and here we > > don't really update the "deleteSubmission" url. > > > > i would hence think HTTP POST would be most appropriate for an "old style > > api". agree ? > > > > That being said, i would like a RESTful API for forms and form > submissions, > > but that's a bigger undertaking ... > > > > My aggregate branch containing the deletesubmission API is here now: > > > > https://github.com/Kapernikov/aggregate/tree/deletesubmission_api > > > > Greetings, > > Frank > > > > > > > > On Thu, Apr 27, 2017 at 10:53 PM, <xiph...@gmail.com > wrote: > >> > >> Oh, and I dont really understand why submission (of 1 record) is under > /, > >> but downloadSubmission (of 1 record) is under /view/. There may be > >> historical reasons for this (?), but its probably something else to > consider > >> normalizing in the API, especially if we're going to expose more APIs. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "ODK Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to opendatakit-developers+unsubscribe@googlegroups.com > . > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "ODK Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to opendatakit-developers+unsubscribe@googlegroups.com > . > For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "ODK Developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/opendatakit-developers/apE33LMmWZI/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > opendatakit-developers+unsubscribe@googlegroups.com . > For more options, visit https://groups.google.com/d/optout. >

Andrew · May 31, 2017, 1:52pm

Hi Matt,

Yaw pointed me to this thread and we've had a look at the GoogleDoc.
A REST API would also be really useful to us - consider this a "+1" /
upvote on the endpoints listed so far.
We've also added an "Add Users" endpoint to the document - something that
will be really useful to us.

We don't have any experience with the Aggregate codebase, but would be keen
to help write this "Add Users" functionality. It would be useful if someone
who knows the codebase better can put the initial API structure in place.

Regards,
Andrew

···

On Tuesday, 16 May 2017 23:45:45 UTC+2, Matthew White wrote: > > Hi all, > > I'm also interested in a REST API for Aggregate, and I've worked with Yaw > and Hélène to create a brainstorming document. Feel free to add your use > cases and any other thoughts, or comment on others'. With a better sense of > the desired functionality, the community can start prioritizing and > figuring out implementation strategies. > > > https://docs.google.com/document/d/1hXqwVs6gnHTutIQOyUmRJyHe8YckkSLrpGaPWDkYCPk/edit?usp=sharing > > I'll go ahead and give everyone in this thread write access. However, > anyone should feel free to request write access. > > Matt > > On Wednesday, May 3, 2017 at 7:47:34 PM UTC-4, Mark Schormann wrote: >> >> Similar to Kate, I would be interested in being involved in a support >> role. I would really like to see the implementation of a RESTful API for >> Aggregate. It has certainly been a pain point, as others have said. >> >> >> >> Regards >> >> Mark >> >> >> >> *From:* opendatakit...@googlegroups.com [mailto: >> opendatakit-developers@googlegroups.com] *On Behalf Of *Kate Chapman >> *Sent:* Thursday, 04 May 2017 12:01 AM >> *To:* opendatakit...@googlegroups.com >> *Cc:* xiph...@gmail.com >> *Subject:* Re: [ODK Developers] Deleting records from ODK Aggregate via >> command line >> >> >> >> I would be interested in assisting with outlining a RESTful API. It has >> certainly been a pain point for me in the past. I'm not that familiar with >> Aggregate so I don't think I'd be a good lead, but I can certainly support. >> >> >> >> -Kate >> >> >> [image: Cadasta Logo] >> >> [image: Grey Divider] >> >> *Kate Chapman* >> *Chief Technology Officer* >> 703.673.8834 | Cadasta.org >> >> >> >> >> >> >> >> >> >> On Wed, May 3, 2017 at 11:06 AM, Yaw Anokwa wrote: >> >> I think the lack of a RESTful API in Aggregate is a big painpoint for >> building integrations, and to be honest, I don't know the best >> approach is to get us there. >> >> A decent first pass is probably to see what Enketo >> (https://apidocs.enketo.org/v2) and Ona >> (https://ona.io/static/docs/index.html) implement first. Then see how >> that fits into OpenROSA's API so we can put together a rough proposal >> for the community to discuss. >> >> Frank/Gareth: Any interest in taking the lead on this? I want to get >> to a point where folks don't have to have forks of Aggregate just to >> get a reasonable API. >> >> Yaw >> >> >> On Fri, Apr 28, 2017 at 3:05 AM, Frank Dekervel wrote: >> > Hello, >> > >> > Thanks for your reply! >> > I think the reason for /view is that there is a special security role >> > associated to everything under /view (right ?) >> > >> > For which HTTP method to use: >> > >> > HTTP GET is out of the question as it would be a security issue (eg i >> could >> > trigger a delete on your system by sending you an IMG >> > SRC="http://opendatakit.appspot.com:8080/deleteSubmission..."/) >> > HTTP DELETE would be logical for a restful api (in which every >> submission >> > had its own url), but the aggregate api is "old style" not rest. >> > HTTP PUT is for updating a certain url in restful semantics, and here we >> > don't really update the "deleteSubmission" url. >> > >> > i would hence think HTTP POST would be most appropriate for an "old >> style >> > api". agree ? >> > >> > That being said, i would like a RESTful API for forms and form >> submissions, >> > but that's a bigger undertaking ... >> > >> > My aggregate branch containing the deletesubmission API is here now: >> > >> > https://github.com/Kapernikov/aggregate/tree/deletesubmission_api >> > >> > Greetings, >> > Frank >> > >> > >> > >> > On Thu, Apr 27, 2017 at 10:53 PM, wrote: >> >> >> >> Oh, and I dont really understand why submission (of 1 record) is under >> /, >> >> but downloadSubmission (of 1 record) is under /view/. There may be >> >> historical reasons for this (?), but its probably something else to >> consider >> >> normalizing in the API, especially if we're going to expose more APIs. >> > >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "ODK Developers" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to opendatakit-developers+unsubscribe@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "ODK Developers" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/opendatakit-developers/apE33LMmWZI/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> opendatakit-developers+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >