webservice: `search` vs. `freeSearch` vs. `attributeSearch`

[ariutta]

For the webservice, I often get the different search types confused:

1. search as in GET /Human/search/1234
2. freeSearch as in GET /Human/isFreeSearchSupported
3. attributeSearch as in GET /Human/attributeSearch/CCR5

Would anyone else find it helpful if we updated the endpoints to make it easier to distinguish between the search types? Here are three sets of alternatives that I find easier to understand:

A

1. GET /Human/identifierSearch/1234
2. GET /Human/isIdentifierSearchSupported => true
3. GET /Human/attributeSearch/CCR5

Note that since BridgeDb is primarily about identifiers, one could argue that search is better than identifierSearch.

B

Webservice could accept a new query parameter named field with a default value of Identifier:

1. GET /Human/search/1234 (equiv. to /Human/search/1234?field=Identifier)
2. GET /Human/isSearchSupported => true (equiv. to /Human/isSearchSupported?field=Identifier)
3. GET /Human/search/CCR5?field=Symbol
4. GET /Human/isSearchSupported?field=Symbol (optional new endpoint)

C

1. GET /Human/identifier/1234
2. GET /Human/searchFields/identifier => true
3. GET /Human/symbol/CCR5
4. GET /Human/searchFields/symbol => true (optional new endpoint)

Not sure about desired capitalization: search_fields vs. searchFields or identifier vs. Identifier, symbol vs. Symbol. Some people recommend not using capital letters in webservice endpoints.

If we changed anything, we'd obviously need to add redirects for backwards compatibility.

[ariutta]

Making a change like this is only worthwhile if there's a general consensus that doing so would make the webservice easier to understand. @egonw made a comment on slack about preferring search over identifierSearch. @egonw, are you not in favor of option A)? How about options B) and C)?

Also, it would be great to hear feedback from @AlexanderPico, @AlasdairGray, @JonathanMELIUS and anyone else interested.

[ariutta]

Closing for lack of interest.