There is lots of great advice on designing message based service APIs here including this:
Group by Call Semantics and Response Types…Every property in each Request DTO has the same semantics that is for SearchProducts each property acts like a Filter (e.g. an AND) whilst in GetProduct it acts like a combinator (e.g. an OR).
Sometime this seems easier said than done. For example, consider an API that gets a grade for a particular student in a particular class and we’d like to select the student either by ID number or by name:
class GetGrade
{
int? id;
string name;
int? class_id;
}
But here the semantics are mixed: (id OR name) AND class_id. We could make it more complex by specifying a specific term_id as well. How to better design this interface? In general what to do when you want multiple flexible selection methods for some criteria AND you need to specify additional filter parameters? Alternately how to better document the interface semantics?
Also the design guidance says:
Keep a consistent Nomenclature
You should reserve the word Get on services which query on unique or Primary Keys fields, i.e. when a supplied value matches a field (e.g. Id) it only Gets 1 result. For “Search Services” that acts like a filter and returns multiple matching results which falls within a desired range we recommend using prefixing Services with the Search or Find verbs to signal the behavior of the Service.
But what about naming for cases where I expect the service to return exactly 1 result, but I must specify multiple filter attributes to get that one result (instead of a PK or uniquely constrained value)?