field-caps.asciidoc 7.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270
  1. [[search-field-caps]]
  2. === Field capabilities API
  3. ++++
  4. <titleabbrev>Field capabilities</titleabbrev>
  5. ++++
  6. Allows you to retrieve the capabilities of fields among multiple indices.
  7. For data streams, the API returns field capabilities among the stream's backing
  8. indices.
  9. [source,console]
  10. --------------------------------------------------
  11. GET /_field_caps?fields=rating
  12. --------------------------------------------------
  13. [[search-field-caps-api-request]]
  14. ==== {api-request-title}
  15. `GET /_field_caps?fields=<fields>`
  16. `POST /_field_caps?fields=<fields>`
  17. `GET /<target>/_field_caps?fields=<fields>`
  18. `POST /<target>/_field_caps?fields=<fields>`
  19. [[search-field-caps-api-desc]]
  20. ==== {api-description-title}
  21. The field capabilities API returns the information about the capabilities of
  22. fields among multiple indices.
  23. The field capabilities API returns <<runtime,runtime fields>> like any
  24. other field. For example, a runtime field with a type of
  25. `keyword` is returned as any other field that belongs to the `keyword` family.
  26. [[search-field-caps-api-path-params]]
  27. ==== {api-path-parms-title}
  28. `<target>`::
  29. (Optional, string)
  30. Comma-separated list of data streams, indices, and index aliases used to limit
  31. the request. Wildcard expressions (`*`) are supported.
  32. +
  33. To target all data streams and indices in a cluster, omit this parameter or use
  34. `_all` or `*`.
  35. [[search-field-caps-api-query-params]]
  36. ==== {api-query-parms-title}
  37. `fields`::
  38. (Required, string)
  39. Comma-separated list of fields to retrieve capabilities for. Wildcard (`*`)
  40. expressions are supported.
  41. include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=allow-no-indices]
  42. +
  43. Defaults to `true`.
  44. include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=expand-wildcards]
  45. +
  46. --
  47. Defaults to `open`.
  48. --
  49. include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=index-ignore-unavailable]
  50. `include_unmapped`::
  51. (Optional, Boolean) If `true`, unmapped fields are included in the response.
  52. Defaults to `false`.
  53. [[search-field-caps-api-request-body]]
  54. ==== {api-request-body-title}
  55. `index_filter`::
  56. (Optional, <<query-dsl,query object>> Allows to filter indices if the provided
  57. query rewrites to `match_none` on every shard.
  58. [[search-field-caps-api-response-body]]
  59. ==== {api-response-body-title}
  60. The types used in the response describe _families_ of field types.
  61. Normally a type family is the same as the field type declared in the mapping,
  62. but to simplify matters certain field types that behave identically are
  63. described using a type family. For example, `keyword`, `constant_keyword` and `wildcard`
  64. field types are all described as the `keyword` type family.
  65. `searchable`::
  66. Whether this field is indexed for search on all indices.
  67. `aggregatable`::
  68. Whether this field can be aggregated on all indices.
  69. `indices`::
  70. The list of indices where this field has the same type family, or null if all indices
  71. have the same type family for the field.
  72. `non_searchable_indices`::
  73. The list of indices where this field is not searchable, or null if all indices
  74. have the same definition for the field.
  75. `non_aggregatable_indices`::
  76. The list of indices where this field is not aggregatable, or null if all
  77. indices have the same definition for the field.
  78. `meta`::
  79. Merged metadata across all indices as a map of string keys to arrays of values.
  80. A value length of 1 indicates that all indices had the same value for this key,
  81. while a length of 2 or more indicates that not all indices had the same value
  82. for this key.
  83. [[search-field-caps-api-example]]
  84. ==== {api-examples-title}
  85. The request can be restricted to specific data streams and indices:
  86. [source,console]
  87. --------------------------------------------------
  88. GET my-index-000001/_field_caps?fields=rating
  89. --------------------------------------------------
  90. // TEST[setup:my_index]
  91. The next example API call requests information about the `rating` and the
  92. `title` fields:
  93. [source,console]
  94. --------------------------------------------------
  95. GET _field_caps?fields=rating,title
  96. --------------------------------------------------
  97. The API returns the following response:
  98. [source,console-result]
  99. --------------------------------------------------
  100. {
  101. "indices": [ "index1", "index2", "index3", "index4", "index5" ],
  102. "fields": {
  103. "rating": { <1>
  104. "long": {
  105. "searchable": true,
  106. "aggregatable": false,
  107. "indices": [ "index1", "index2" ],
  108. "non_aggregatable_indices": [ "index1" ] <2>
  109. },
  110. "keyword": {
  111. "searchable": false,
  112. "aggregatable": true,
  113. "indices": [ "index3", "index4" ],
  114. "non_searchable_indices": [ "index4" ] <3>
  115. }
  116. },
  117. "title": { <4>
  118. "text": {
  119. "searchable": true,
  120. "aggregatable": false
  121. }
  122. }
  123. }
  124. }
  125. --------------------------------------------------
  126. // TESTRESPONSE[skip:historically skipped]
  127. <1> The field `rating` is defined as a long in `index1` and `index2`
  128. and as a `keyword` in `index3` and `index4`.
  129. <2> The field `rating` is not aggregatable in `index1`.
  130. <3> The field `rating` is not searchable in `index4`.
  131. <4> The field `title` is defined as `text` in all indices.
  132. By default unmapped fields are ignored. You can include them in the response by
  133. adding a parameter called `include_unmapped` in the request:
  134. [source,console]
  135. --------------------------------------------------
  136. GET _field_caps?fields=rating,title&include_unmapped
  137. --------------------------------------------------
  138. In which case the response will contain an entry for each field that is present
  139. in some indices but not all:
  140. [source,console-result]
  141. --------------------------------------------------
  142. {
  143. "indices": [ "index1", "index2", "index3" ],
  144. "fields": {
  145. "rating": {
  146. "long": {
  147. "searchable": true,
  148. "aggregatable": false,
  149. "indices": [ "index1", "index2" ],
  150. "non_aggregatable_indices": [ "index1" ]
  151. },
  152. "keyword": {
  153. "searchable": false,
  154. "aggregatable": true,
  155. "indices": [ "index3", "index4" ],
  156. "non_searchable_indices": [ "index4" ]
  157. },
  158. "unmapped": { <1>
  159. "indices": [ "index5" ],
  160. "searchable": false,
  161. "aggregatable": false
  162. }
  163. },
  164. "title": {
  165. "text": {
  166. "indices": [ "index1", "index2", "index3", "index4" ],
  167. "searchable": true,
  168. "aggregatable": false
  169. },
  170. "unmapped": { <2>
  171. "indices": [ "index5" ],
  172. "searchable": false,
  173. "aggregatable": false
  174. }
  175. }
  176. }
  177. }
  178. --------------------------------------------------
  179. // TESTRESPONSE[skip:historically skipped]
  180. <1> The `rating` field is unmapped` in `index5`.
  181. <2> The `title` field is unmapped` in `index5`.
  182. It is also possible to filter indices with a query:
  183. [source,console]
  184. --------------------------------------------------
  185. POST my-index-*/_field_caps?fields=rating
  186. {
  187. "index_filter": {
  188. "range": {
  189. "@timestamp": {
  190. "gte": "2018"
  191. }
  192. }
  193. }
  194. }
  195. --------------------------------------------------
  196. // TEST[setup:my_index]
  197. In which case indices that rewrite the provided filter to `match_none` on every shard
  198. will be filtered from the response.
  199. --
  200. [IMPORTANT]
  201. ====
  202. The filtering is done on a best-effort basis, it uses index statistics and mappings
  203. to rewrite queries to `match_none` instead of fully executing the request.
  204. For instance a `range` query over a `date` field can rewrite to `match_none`
  205. if all documents within a shard (including deleted documents) are outside
  206. of the provided range.
  207. However, not all queries can rewrite to `match_none` so this API may return
  208. an index even if the provided filter matches no document.
  209. ====
  210. --