Search the database using a string query, structured query, a cts:query, or a combined query in the POST body. Returns search results, matching content and/or metadata, or both.
URL Parameters | |
---|---|
q? | A string query conforming to the Search API grammar. For details, see Automatic Query Text Parsing and Grammar in the Search Developer's Guide This query is AND'd with the query(s) in the request body. |
start? | The index of the first result to return. The first result is index 1. Default: 1. |
pageLength? | The maximum number of results to return in this request. Default: 10, or the length configured by the query options. |
options? |
The name of query options previously created via a PUT or POST
request to the /v1/config/query service.
|
view? |
The view of the search results to return in the response. Accepted
values: facets, results, metadata, all (default)
for a normal search, none for a multi-document read.
|
category* |
The category of data to fetch about the matching documents. Category
can be specified multiple times to retrieve any combination of content
and metadata. Valid categories: content (default),
metadata , metadata-values ,
collections , permissions ,
properties , and quality .
Use metadata to request all
categories except content . You can only use this
parameter when making a multi-document read request.
|
database? | Perform this operation on the named content database instead of the default content database associated with the REST API instance. Using an alternative database requires the "eval-in" privilege; for details, see Security Requirements in the REST Application Developer's Guide. |
format? |
You can use this parameter in conjunction with or instead of the
request Content-type and Accept headers to indicate the input
and/or output content type. The Content-type header takes precedence
over format in most cases. The format parameter
always takes precedence over the Accept header. For details, see
Controlling Input and Output Content Type in the REST Application Developer's Guide.
Accepted values: json or xml .
|
txid? |
The transaction identifier of the multi-statement transaction in
which to service this request. Use the /transactions
service to create and manage multi-statement transactions.
|
collection* | Filter search results so they include only matches in the named collection. If you specify this parameter multiple times, the collections are OR related. |
directory? | Filter search results so they only include matches from documents in the specified database directory. |
transform? |
Names a search result transformation previously installed via the
/transforms service. If a search response is returned,
the transformation is applied
to the <search:response/> after applying
user-defined transforms defined in the query options using
<transform-results> . For details, see
Transforming the Search Response in the REST Application Developer's Guide.
On a multi-document read request, the transform is applied to each
returned document as well as the search response (if a search response
is requested).
|
timestamp? |
A timestamp returned in the ML-Effective-Timestamp
header of a previous request. Use this parameter to iteratively
fetch search results based the contents of the database at a fixed
point-in-time. For more details, see
Performing Point-in-Time Operations in the REST Application Developer's Guide.
|
trans:{name}* |
A transform parameter name and value. For example,
trans:myparam=1 . Transform parameter values are passed to
the transform named in the transform request parameter.
|
forest-name* | The name of forest(s) to which results should be limited. The forest(s) must exist in the database for this request. If you wish to retrieve results from multiple specific forests, specify this parameter once per forest. |
Request Headers | |
---|---|
Accept |
The expected MIME type of the response. Accepted values:
application/json , application/xml ,
multipart/mixed . Default: application/xml .
When you use multipart/mixed , the request is a multi-document
read rather than just a search; see the Usage Notes. If the Accept
header and format parameter are both present, then
format takes precedence if the Accept header is not
set to multipart/mixed . For details, see
Controlling Input and Output Content Type in the REST Application Developer's Guide.
|
Content-Type* |
The MIME type of the data in the POST body. Accepted values:
application/json or application/xml .
The format parameter value is used if Content-type is not
set or is set to an incompatible or unknown value.
|
Response Headers | |
---|---|
Content-Type |
The MIME type of the data in the response. For a normal search
operation, the results are either XML or JSON, depending upon the
value of the format parameter or the Accept header.
For a multi-document read, the result is a multipart/mixed response
body containing matching content and/or metadata; see the Usage Notes.
|
ML-Effective-Timestamp |
The system timestamp at which this operation was performed. You
can use the value in the timestamp parameter of a
subsequent request. For more details, see
Performing Point-in-Time Operations in the REST Application Developer's Guide.
|
vnd.marklogic.start |
For a multi-document read operation, the starting index of the
results in the response. The header value is always 1 unless you
use the start and pageLength parameters
to incrementally retrieve results.
|
vnd.marklogic.pageLength |
For a multi-document read operation, the number of results in
the response. See the pageLength parameter.
|
vnd.marklogic.result-estimate |
For a multi-document read operation, an estimate of the total number
of matches to the input query. This is equivalent to total
in the search:response .
|
For a normal search operation, MarkLogic Server returns a 200 (OK) status,
whether there are search matches or not. If XML output is requested, the
response body contains a search:reponse
node. If JSON output
is requested, the response body contains a JSON map with keys that closely
correspond to the search:response
elements.
For a multi-document read, by default MarkLogic Server returns status
200 (OK) only if there are matching documents and a 404 (Not Found) if
there are no matching documents. If you use the view
request parameter to include search results or facets in the response,
then the return status is 200 (OK) whether there are matching documents
or not.
For a multi-document read, the response body is multipart/mixed data
containing content and/or metadata for each document that matches the
input query. If you use a view
parameter to include
search results in the response, the search response, facets, or metadata
are in the first part. For details, see
Reading Multiple Documents Matching a Query in the REST Application Developer's Guide.
rest-reader
role, or the
following privilege:
http://marklogic.com/xdmp/privileges/rest-reader
You can use this request as a simple database search operation that returns
search results, or a multi-document read of content and/or metadata
matching a query. A multi-document read can also return search results,
but does not do so by default; see the view
parameter.
A multi-document read is distinguished from a normal search operation
by setting the Accept header to multipart/mixed
.
For details, see Reading Multiple Documents Matching a Query in the REST Application Developer's Guide and Querying Documents and Metadata in the REST Application Developer's Guide.
The request body must contain either a structured query (a serialized
representation of a search:query
), a serialized cts:query,
or a combined query (a serialized representation of a
search:search
), expressed as either XML or JSON.
For details, see
Searching Using Structured Queries in the Search Developer's Guide and
Specifying Dynamic Query Options with Combined Query in the REST Application Developer's Guide.
When performing a multi-document read, use the category
parameter to specify whether to return content, metadata, and/or a
metadata subset for matching documents. By default, only content is
returned. Use the view
parameter to include search results
and facets in the response. You can also use the view
parameter to control results in a normal search operation.
For a normal search operation, you should usually use the Accept
and Content-type headers to control the input and output content type.
The format
parameter is available as a fallback and as a
means to indicate search result and metadata content type on a
multi-document read.
Supply query options with the options
request parameter
or in the request body. If no query options are specified in
either the request parameter or the request body, MarkLogic Server uses
the configured default options. If no default options are configured,
MarkLogic Server uses the default Search API options.
If the body contains a structured or cts query, use the options
request parameter to specify custom query options. If the body contains
a combined query, use the options
request parameter
and/or the options
component of the combined query.
If query options are supplied in both the options
request
parameter and the request body, the options are merged together. In cases
of conflict, an option definition in the combined query overrides the
one in the persistent options. Constraints defined in both option sources
are preserved; in the event of a constraint name collision, the constraint
defined in the request body takes precedence.
Query options named in the options
request parameter must
be pre-installed using the /config/query
service.
A combined query encapsulates options and query in a single object. A combined query is most often used to specify options plus one or more queries at query time, but you can also specify only options or only one or more queries. The query portion can be a string query; a structured, cts, or QBE query; or both a string query and a structured, cts, or QBE query. For syntax, semantics, and examples, see Specifying Dynamic Query Options with Combined Query in the REST Application Developer's Guide.
The query options within a combined query use the same option syntax as standalone, persistent query options; for details, see Appendix: Query Options Reference in the Search Developer's Guide. Similarly, the sub-queries in a combined query use the syntax of a standalone structured, cts, QBE, or string query.
When you use the collection
and directory
parameters to limit the scope of a search, the effect of these parameters
on the search is not reflected in the query returned when you
use the return-query
query option. If you need to see these
constraints reflected in the returned query, use a structured query that
includes a collection-query
or directory-query
instead.
The metadata-values
category represents "metadata fields"
document metadata. For more details, see
Metadata Fields in the Administrator's Guide.
# Search using an XML structured query in the request body $ cat > s-query.txt <search:query xmlns:search="http://marklogic.com/appservices/search"> <search:near-query> <search:term-query> <search:text>infinite</search:text> </search:term-query> <search:term-query> <search:text>variety</search:text> </search:term-query> <search:distance>3</search:distance> </search:near-query> </search:query> ^D $ curl --anyauth --user user:password -X POST -d@'./s-query.txt' -i \ -H "Content-type:application/xml" -H "Accept: application/xml" \ http://localhost:8000/v1/search ==> Perform a query for "infinite" occurring within 3 terms of "variety", and receive the search:response XML results in the response body. The response has the following form: Server: MarkLogic Content-Type: text/plain; charset=UTF-8 Content-Length: 31 Connection: close HTTP/1.1 200 OK Content-type: application/xml Server: MarkLogic Content-Length: 875 Connection: close <search:response total="1" start="1" page-length="10" xmlns="" xmlns:search="http://marklogic.com/appservices/search"> <search:result index="1" uri="/shakespeare/plays/a_and_c.xml" path="fn:doc("/shakespeare/plays/a_and_c.xml")" score="43648" confidence="0.418356" fitness="0.50947"> <search:snippet> <search:match path="..."> Her <search:highlight>infinite</search:highlight> <search:highlight>variety</search:highlight>: other women cloy </search:match> </search:snippet> </search:result> <search:metrics> <search:query-resolution-time> PT1.087968S </search:query-resolution-time> <search:snippet-resolution-time> PT1.028637S </search:snippet-resolution-time> <search:total-time>PT2.117041S</search:total-time> </search:metrics> </search:response>
# Search using a JSON structured query in the request body $ cat > s-query.json {"query": { "near-query": { "queries": [ {"term-query": { "text" : "infinite"}}, {"term-query": { "text" : "variety" }} ], "distance": 3 } }} ^D $ curl --anyauth --user user:password -X POST -d@'./s-query.json' -i \ -H "Content-type:application/json" -H "Accept: application/json" \ http://localhost:8000/v1/search ==> Perform a query for "infinite" occurring within 3 terms of "variety", and receive the JSON results in the response body. The response has the following form: Content-Type: application/json; charset=utf-8 Content-Length: 104 Connection: Keep-Alive Keep-Alive: timeout=5 HTTP/1.1 200 OK Content-type: application/json; charset=utf-8 ML-Effective-Timestamp: 14964190204445650 Server: MarkLogic Content-Length: 696 Connection: Keep-Alive Keep-Alive: timeout=5 { "snippet-format": "snippet", "total": 1, "start": 1, "page-length": 10, "results": [ { "index": 1, "uri": "/shakespeare/plays/a_and_c.xml", "path": "fn:doc(\"/shakespeare/plays/a_and_c.xml\")", "score": 47744, "confidence": 0.43916, "fitness": 0.513595, "href": "/v1/documents?uri=%2Fshakespeare%2Fplays%2Fa_and_c.xml&database=bill", "mimetype": "application\/xml", "format": "xml", "matches": [ { "path": "fn:doc(\"/shakespeare/plays/a_and_c.xml\")/PLAY/ACT[2]/SCENE[2]/SPEECH[86]/LINE[3]", "match-text": [ "Her ", { "highlight": "infinite" }, " ", { "highlight": "variety" }, ": other women cloy" ] } ] } ], "metrics": { "query-resolution-time": "PT0.001632S", "snippet-resolution-time": "PT0.448131S", "total-time": "PT0.450721S" } }
# Search using a cts:query in the request body $ cat > cts-query.txt <cts:near-query distance="3" xmlns:cts="http://marklogic.com/cts"> <cts:word-query> <cts:text xml:lang="en">infinite</cts:text> </cts:word-query> <cts:word-query> <cts:text xml:lang="en">variety</cts:text> </cts:word-query> </cts:near-query> ^D $ curl --anyauth --user user:password -X POST -d@'./cts-query.txt' -i \ -H "Content-type:application/xml" http://localhost:8000/v1/search ==> Perform a query for "infinite" occurring within 3 terms of "variety", and receive the search:response XML results in the response body. The response has the following form: Server: MarkLogic Content-Type: text/plain; charset=UTF-8 Content-Length: 31 Connection: close HTTP/1.1 200 OK Content-type: application/xml Server: MarkLogic Content-Length: 875 Connection: close <search:response total="1" start="1" page-length="10" xmlns="" xmlns:search="http://marklogic.com/appservices/search"> <search:result index="1" uri="/shakespeare/plays/a_and_c.xml" path="fn:doc("/shakespeare/plays/a_and_c.xml")" score="43648" confidence="0.418356" fitness="0.50947"> <search:snippet> <search:match path="..."> Her <search:highlight>infinite</search:highlight> <search:highlight>variety</search:highlight>: other women cloy </search:match> </search:snippet> </search:result> <search:metrics> <search:query-resolution-time> PT1.087968S </search:query-resolution-time> <search:snippet-resolution-time> PT1.028637S </search:snippet-resolution-time> <search:total-time>PT2.117041S</search:total-time> </search:metrics> </search:response> # The following is the equivalent JSON cts:query serialization: {"ctsquery":{ "nearQuery":{ "queries":[ {"wordQuery":{"text":["infinite"], "options":["lang=en"]}}, {"wordQuery":{"text":["variety"], "options":["lang=en"]}} ], "distance":3 }} }
# Search using a combined query in the request body $ cat ./combined-query.xml <search xmlns="http://marklogic.com/appservices/search"> <qtext>alas</qtext> <query> <near-query> <term-query> <text>Yorick</text> </term-query> <term-query> <text>Horatio</text> </term-query> </near-query> </query> <options> <return-results>false</return-results> <return-metrics>false</return-metrics> </options> </search> $ curl --anyauth --user user:password -X POST -d@./combined-query.xml \ -i -H "content-type: application/xml" http://localhost:8000/v1/search ==> Perform a query for "Yorick" near "Horatio", using a combined query. Dynamic options in the POST body disable returning results and metrics. The response has the following form: HTTP/1.1 200 OK Content-type: application/xml; charset=utf-8 Server: MarkLogic Content-Length: 189 Connection: Keep-Alive Keep-Alive: timeout=5 <search:response snippet-format="snippet" total="1" start="1" page-length="10" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="" xmlns:search="http://marklogic.com/appservices/search"/> The following is the equivalent combined query request body as JSON: { "search": { "qtext" : "alas", "query" : { "near-query" : { "term-query" : [ {"text" : "Yorick"}, {"text":"Horatio" } ] } }, "options" : { "return-results" : false, "return-metrics" : false } } }