Keeping or not the filteringTerms.yaml inside every entry type folder

[costero-e]

First message of the issue #93, opening by @mbaudis.
I think the first point of the solution proposed here is the one I would adopt, deleting the filteringTerms.yaml files for each endpoint, as it is not strictly needed.

[redmitry]

deleting the filteringTerms.yaml

filteringTerms.yaml is a reference implementation thing.
The question is should we remove /filtering_terms endpoints from endpoints?

beacon-v2/models/json/beacon-v2-default-model/individuals/endpoints.json

Line 152 in d2be0e2

"/individuals/filtering_terms": {

(or this was an error from the beginning?).

Will "filteringTermsUrl" in the /map have sense if there is a standard /filtering_terms endpoint?

D.

[mbaudis]

filteringTerms.yaml is a reference implementation thing.

Yes, no place in the model (as file).

The question is should we remove /filtering_terms endpoints from endpoints?

A) It shouldn't be there and we use scopes.
B) It should be there for all entyry types w/ "filters" option - but then we don't need scopes...

In any case the files don't make sense in the model.

[redmitry]

I'm for the "A".
the rationale:

1. one single place for filters (simplifies things, especially in the BN).
2. endpoints for entry types kept free from auxiliary stuff.

[costero-e]

I agree that if we add a multiscope field inside the filtering terms object, we can get rid of the specific filtering terms endpoints and just keep a general filtering terms endpoint. I will create a new branch for this feature this week to start working on this.

[jrambla]

Addressed in PR #167 pending review