Glossary

This page explains some of the lingo specific to the Search API.

Index

A configuration object for indexing data of a specific type. What and how data is indexed is determined by its settings. Also keeps track of which items still need to be indexed (or re-indexed, if they were updated). Needs to lie on a server in order to be really used (although configuration is independent of a server).
For example, you could have a "Node index" for indexing nodes. It would contain the fields that should be indexed and their types, the data alterations and processors to use and some other settings. The details of how to index data are independent of these settings, and server-specific. Other modules who build functionality on the Search API, like by providing ways to search, etc., always reference the index as the source of the search data. This way, they also are independent of the inner mechanics of the search server.

Server

A concrete way to index and search data. It could, e.g., represent a certain database, a connection to an external search server, etc. How exactly the data is stored is determined by the server's service class, but is not important for the overall functionality of the Search API.
A server can have an arbitrary number of indexes attached to it, whose search data is then indexed on that server.

Service class

Identifies the type of server backend which is used for a server, thereby specifying how the data will be indexed and searched. For instance, there are service classes available which will use databases, Solr servers, Xapian servers, MongoDB instances, etc., for indexing and searching data. When creating a server, a service class has to be chosen

Item type

A type of data which can be indexed by the Search API. Each index is usually associated with one such type (but there can be multiple indexes for the same type), which specifies what kind of items will be indexed there. There is also possibility to create multiple-type index.
Most item types correspond to entity types with the same name (nodes, users, taxonomy terms, …), but there can also be additional item types defined by contrib modules which need not be entity types.

Field / Property

A defined property of an item, like a node's title or a user's mail address. Although fields defined by the Field API are available as Search API fields, too, the meaning of the term "field" is different in this context, as it also encompasses all native or derived properties not set by the Field API.
All fields have defined datatypes. However, for indexing purposes the user might choose to index a field under a different data type than defined.

Data type

Determines how a field is indexed. While "Fulltext" fields can be completely searched for keywords, other fields can only be used for filtering. They will also be converted to fit their respective value ranges.
How types other than "Fulltext" are handled depends on the service class used. Its documentation should state how the type-selection affects the indexed content. Service classes will always be able to handle all data types, it is just possible that the type doesn't affect the indexing at all (apart from "Fulltext vs. the rest").

Boost

Number determining how important a certain field is, when searching for fulltext keywords. The higher the value is, the more important is the field. E.g., when the node title has a boost of 5.0 and the node body a boost of 1.0, keywords found in the title will increase the score as much as five keywords found in the body. Of course, this has only an effect when the score is used (for sorting or other purposes). It has no effect on other parts of the search result.

Data alteration

A component that is used when indexing data. It can add additional fields to the indexed entity or prevent certain entities from being indexed. Fields added by callbacks have to be enabled on the "Fields" page to be of any use but this is done by default.

Processor

An object that is used for preprocessing indexed data as well as search queries, and for postprocessing search results. Usually only work on fulltext fields to control how content is indexed and searched. E.g., processors can be used to make searches case-insensitive, to filter markup out of indexed content, etc.