The resources use a data model that is supported by a set of client-side libraries that are made available on the files and libraries page.
You may also enjoy the interactive interface provided for this API by Swagger.
| name | path | methods | description |
|---|---|---|---|
| ZHwebResourceImpl |
|
|
| type | description |
|---|---|
| DefaultSearchRequestContext | |
| DefaultSearchResponseContext | |
| DeleteRequest | The request for deleting one document from an index. |
| IndexChangeRequest | The request for changing the index. |
| InsertRequest | The request for inserting a document into the index. The fields are the analyzed fields for Elasticsearch (there is no MCS3 specific analysis or mapping done in any way). This is usually not the way to insert documents. |
| SanityResponse | Response to a sanity request |
| SanityState | Enumeration of all sanity states the service can be in.
|
| SearchFacet | A search facet contains per field all values and counts of the totally matching documents. The count is always on the unclustered ranklist with restrictions applied. |
| SearchHit | A single hit of a search ranklist. Only the rank, the docid and the score are always returned. If you want to get more fields, you have to specify them in the request field SearchRequest#fields. |
| SearchOption | Available search options.
|
| SearchRequest | |
| SearchResponse | Response to a search request. Contains a list of search hits, facets and additional information like similar terms, corrected query, etc. |
| SearchResponseContext | |
| SearchRestriction | A single hit of a search ranklist. Only the rank, the docid and the score are always returned. If you want to get more fields, you have to specify them in the request field SearchRequest#fields. |
| SearchRestrictionMode | How search restrictions should be applied.
|
| SearchRestrictionOperator | What is the operator of the condition on the field.
|
| SearchSorting | Search options define how the ranklist should be calculated. You can specify multiple search orders, in this case they take precedence in the order of definition, so for instance if you sort by score, then by date only documents with the same score get sorted by date as second criterion. Each search options has a field you want to sort by and a sort order (descending or ascending). To order by score you have to specify the pseudo field 'score'. In this case only sorting order DESCENDING makes really sense. Otherwise you can specify any index field which is properly indexed and has a sorting order. |
| SearchSortingOrder | Enumeration of how we can sort a ranklist.
|
| SimilarTerm | A similar term is a term which is somehow related to the term(s) in the original query. The result is the matching term, a reason (which provider plugin is returning this matching term) and a priority which can be used to pick the best similar terms. |
| SuggestRequest | The request for a suggestion. |
| SuggestResponse | The response to a suggestion request. |
| Suggestion | One suggestion hit. |
| VersionResponse | Response to a request of the version of the API, contains major and minor of the version. |
| ZHwebMostFrequentTermsRequest | |
| ZHwebMostFrequentTermsResponse | |
| ZHwebSearchRequest | |
| ZHwebSearchRequestContext | |
| ZHwebSearchResponse | Response to a project-specific search request (@see ZHwebSearchRequest). |
| ZHwebSearchResponseContext | |
| ZHwebTermStat |