stac_api/
root.rs

1use crate::Conformance;
2use serde::{Deserialize, Serialize};
3use stac::Catalog;
4
5/// The root landing page of a STAC API.
6///
7/// In a STAC API, the root endpoint (Landing Page) has the following characteristics:
8///
9///   - The returned JSON is a [STAC
10///     Catalog](../stac-spec/catalog-spec/catalog-spec.md), and provides any number
11///     of 'child' links to navigate to additional
12///     [Catalog](../stac-spec/catalog-spec/catalog-spec.md),
13///     [Collection](../stac-spec/collection-spec/README.md), and
14///     [Item](../stac-spec/item-spec/README.md) objects.
15///   - The `links` attribute is part of a STAC Catalog, and provides a list of
16///     relations to API endpoints. Some of these endpoints can exist on any path
17///     (e.g., sub-catalogs) and some have a specified path (e.g., `/search`), so
18///     the client must inspect the `rel` (relationship) to understand what
19///     capabilities are offered at each location.
20///   - The `conformsTo` section provides the capabilities of this service. This
21///     is the field that indicates to clients that this is a STAC API and how to
22///     access conformance classes, including this one. The relevant conformance
23///     URIs are listed in each part of the API specification. If a conformance
24///     URI is listed then the service must implement all of the required
25///     capabilities.
26#[derive(Debug, Serialize, Deserialize)]
27pub struct Root {
28    /// The [stac::Catalog].
29    #[serde(flatten)]
30    pub catalog: Catalog,
31
32    /// Provides the capabilities of this service.
33    ///
34    /// This is the field that indicates to clients that this is a STAC API and
35    /// how to access conformance classes, including this one. The relevant
36    /// conformance URIs are listed in each part of the API specification. If a
37    /// conformance URI is listed then the service must implement all of the
38    /// required capabilities.
39    ///
40    /// Note the `conformsTo` array follows the same structure of the OGC API -
41    /// Features [declaration of conformance
42    /// classes](http://docs.opengeospatial.org/is/17-069r3/17-069r3.html#_declaration_of_conformance_classes),
43    /// except it is part of the landing page instead of in the JSON response
44    /// from the `/conformance` endpoint. This is different from how the OGC API
45    /// advertises conformance, as STAC feels it is important for clients to
46    /// understand conformance from a single request to the landing page.
47    /// Implementers who implement the *OGC API - Features* and/or *STAC API -
48    /// Features* conformance classes must also implement the `/conformance`
49    /// endpoint.
50    ///
51    /// The scope of the conformance classes declared in the
52    /// `conformsTo` field and the `/conformance` endpoint are limited to the
53    /// STAC API Catalog that declares them. A STAC API Catalog may link to
54    /// sub-catalogs within it via `child` links that declare different
55    /// conformance classes. This is useful when an entire catalog cannot be
56    /// searched against to support the *STAC API - Item Search* conformance
57    /// class, perhaps because it uses multiple databases to store items, but
58    /// sub-catalogs whose items are all in one database can support search.
59    /// #[serde(rename = "conformsTo")]
60    #[serde(flatten)]
61    pub conformance: Conformance,
62}
stac_api/root.rs

stac_api/
root.rs
