17
edits
Search API V3: Difference between revisions
API Updates
No edit summary |
(API Updates) |
||
| Line 63: | Line 63: | ||
** Apply those writes | ** Apply those writes | ||
=== API === | === API Overview === | ||
Each API will return a maximum of 100 items. These APIs should also be unit tested. After these API changes are done, they should be exposed in the docs. | Each API will return a maximum of 100 items. These APIs should also be unit tested. After these API changes are done, they should be exposed in the docs. | ||
| Line 121: | Line 121: | ||
</pre> | </pre> | ||
=== API Discussion === | |||
The barcode GET API is included to demonstrate how this service could easily replace our existing APIs, but is not intended to be used. | |||
The remaining APIs have several commonalities: | |||
* Only fields with a value are returned in the JSON response, to keep response size down without needing to specify fields manually | |||
* An optional ''response_fields'' parameter is provided, to limit the fields in the response further | |||
* POST is used, to support a complex request body | |||
The ''/search'' API is the most complex as it allows a series of filters to support the use cases in the current API. These filters will work like an intersection/AND query. Of interest are the: | |||
* ''like'' operator, which does not need to match to exact fields, but rather will match by use of the snowball token filter in Elasticsearch if the field supports it. | |||
* ''gt'', ''lt'' (greater than, less than) operators are provided. | |||
* To maintain backwards compatibility, a ''without'' operator is provided, in which case the value will be ignored. Note that the value is still required, so a dummy value should be used (it was feared that making this optional would lead to client side bugs). This should be well documented. | |||
== Work Plan == | == Work Plan == | ||