In today's blog, I want to briefly introduce the search API and its features. As with other APIs, the search API also a protocol for communication between applications. It is an XQuery library that combines searching, search parsing, search grammar, search term completion, and other search application features into a single API.You can interact with the search API through XQuery, REST, Node.js, and Java, using a variety of query styles. The search:search function takes search terms, parses them into an appropriate cts:query, and returns a response with snippets and URIs for matching nodes in the database. You can get started with the search API with a very simple query:
xquery version "1.0-ml"; import module namespace search = "http://marklogic.com/appservices/search" at "/MarkLogic/appservices/search/search.xqy"; search:search("hello world") => <search:response total="1" start="1" page-length="10" xmlns="" xmlns:search="http://marklogic.com/appservices/search"> <search:result index="1" uri="/hello.xml" path="doc("/hello.xml")" score="136" confidence="0.67393" fitness="0.67393"> <search:snippet> <search:match path="doc("/hello.xml")/hello">This is where you say "<search:highlight>Hello</search:highlight> <search:highlight>World</search:highlight>". </search:match> </search:snippet> </search:result> <search:qtext>hello world</search:qtext> <search:metrics> <search:query-resolution-time>PT0.328S </search:query-resolution-time> <search:total-time>PT0.352S</search:total-time> </search:metrics> </search:response>
The output is a search:response element, and it contains everything needed to build a search results page. It includes an estimate of the total number of documents that match the search, the URI and XPath for each result, pagination of the search results, a snippet of the results' content, the original query text submitted, and metrics on the response time. You can customize the data returned in each search:result using the result-decorator query option.
Nowadays, there is a competitor for the search API: Streaming API. The slight differences between the two APIs are listed below:
Search goes back in time, and streaming goes forward. When you first decide to collect data on a subject, you have nothing to start with. The search API is best used to fill in the past seven days for your subject matter. This is often called back-filling.
Both the search API and streaming API need login credentials for all requests.
You are only allowed to make a single streaming API OAuth connection for each account that owns the app. No matter how many people log into your site, the app they all log into can only use a single streaming API connection. The search API, on the other hand, allows a separate rate limited bucket of requests for each user who logs into your app.
Data formats are almost the same.
The search API has a fairly rich set of operators that can filter results based on attributes like location of sender, language, and various popularity measurements.
The streaming API can collect all tweets that contain up to 400 keyword phrases, sent by up to 5,000.
That's all for now, I'll catch you in the next session with some more blogs.