implementing /contributions/count endpoint

[FabiKo117]

Description

Implementation of new endpoint /contributions/count

Corresponding issue

#115

New or changed dependencies

• none

Checklist

• controller
• response format
• processing
• swagger endpoint + example parameters
• restructuring of controller and output packages #124 needs to be merged
• My code follows the code-style rules, and I have checked on the static analyses
• I have commented my code
• I have written javadoc (required for public methods)
• Add info about this feature being experimental to docs
• I have added sufficient unit and API tests
• I have made corresponding changes to the documentation
• I have updated the CHANGELOG.md
  I have adjusted the examples in the check-ohsome-api script or created an issue in the corresponding repository. More Information here.

[bonaparten]

I know that we should avoid boilerplate code, but let some classes of the contributions endpoints be used by classes of the users endpoints could be misleading. Here some points:

• The UsersController.java uses the ContributionsExecutor.java
• The ContributionsResult.java is called by classes of users endpoints like the UsersRequestExecutor.java
• The method "count" in the class ContributionsExecutor is now used for users/count
• The method writeCsvResponse in AggregateRequestExecutor.java uses ContributionsResults.java even if this class is supposed to be used only for /elements and /elements/_/groupBy/boundary endpoints.

Refactoring some classes and let them "extend" other in-between classes could be a solution.

//edit: adding a get test would be probably fine.

[FabiKo117]

* The UsersController.java uses the ContributionsExecutor.java

This is because the /users endpoint also uses the contribution-view of the OSHDB, hence their processing is similar. We could think about renaming the executor classes then in a way that this is better reflected and cannot be mixed up with the name of the endpoint /contributions. This would be one thing that should be performed with the general refactoring including the extension of the AggregageRequestExecutor class, which is not working for every endpoint yet too.

* The ContributionsResult.java is called by classes of users endpoints like the UsersRequestExecutor.java

Same reason as described above.

* The method "count" in the class ContributionsExecutor is now used for users/count

Again same reason.

* The method writeCsvResponse in AggregateRequestExecutor.java uses ContributionsResults.java even if this class is supposed to be used only for /elements and  /elements/_/groupBy/boundary endpoints.

This is indeed not so nice code-quality wise. But this behavior did not get introduced with this branch. It was already before using the /users endpoint. But you are right here, this would also have to be refactored. Maybe we can create something like a GenericRequestExecutor that holds methods like writeCsvResponse which are used through different endpoint and processing structures?

Refactoring some classes and let them "extend" other in-between classes could be a solution.

//edit: adding a get test would be probably fine.

I don't understand what you mean with these two points. A test for what exactly?

[bonaparten]

* The method writeCsvResponse in AggregateRequestExecutor.java uses ContributionsResults.java even if this class is supposed to be used only for /elements and  /elements/_/groupBy/boundary endpoints.

This is indeed not so nice code-quality wise. But this behavior did not get introduced with this branch. It was already before using the /users endpoint. But you are right here, this would also have to be refactored. Maybe we can create something like a GenericRequestExecutor that holds methods like writeCsvResponse which are used through different endpoint and processing structures?

We have this method also in ExecutionUtils.java. Yes, this could be a solution. Could you please change the javadoc upon AggregateRequestExecutor adding that it is used also for the contributions endpoints?

Refactoring some classes and let them "extend" other in-between classes could be a solution.
//edit: adding a get test would be probably fine.

I don't understand what you mean with these two points. A test for what exactly?

Like you already said with the class GenericRequestExecutor, I meant to create some superclasses and interfaces where needed in order to achieve more inheritance and structure.
I saw you added some tests for POST requests, you could also add some tests for GET requests.

[FabiKo117]

@bonaparten I've updated the javadoc.

I saw you added some tests for POST requests, you could also add some tests for GET requests.

It does not matter what type of HTTP request is used in the tests, as the content of GET and POST is processed equally within the code. This was different in earlier versions of the code, but now there is no difference in the processing.

[tyrasd]

I noticed that this new endpoint still supports the old types/keys/values syntax. I'd rather not have deprecated functionality included with new endpoints. Same as already discussed in #34 (review)