|
1 | 1 |
|
2 |
| -# Catalog API Specification |
| 2 | +# SpatioTemporal Asset Catalog API Specification |
3 | 3 |
|
4 |
| -This folder specifies the dynamic version of SpatioTemporal Asset Catalog - the Catalog API. For now the complete |
5 |
| -definition is contained in the [spec.yaml](spec.yaml) file, which is an [OpenAPI](http://openapis.org) 2.0 (swagger) |
6 |
| -yaml document. In time more narrative will be added describing the decisions and recommendations on implementing |
7 |
| -the STAC API. |
| 4 | +## Overview |
8 | 5 |
|
9 |
| -The easiest way to explore the specification in a more human readable way is to load the file up in to the |
10 |
| -[online swagger editor](http://editor.swagger.io). You can import the spec by just selectiong 'file' -> |
11 |
| -'import url' and enter <https://raw.githubusercontent.com/radiantearth/stac-spec/dev/api-spec/spec.yaml>. |
| 6 | +A STAC API is the dynamic version of a SpatioTemporal Asset Catalog. It returns [STAC Items](../json-spec/json-spec.md) |
| 7 | +(GeoJSON objects with required links time stamp and links to assets) from search queries on a RESTful endpoint. |
| 8 | + |
| 9 | +The core of the spec is a single endpoint: |
| 10 | + |
| 11 | +``` |
| 12 | +/search/stac |
| 13 | +``` |
| 14 | + |
| 15 | +It takes a JSON object that can filter on date and time: |
| 16 | + |
| 17 | +``` |
| 18 | +
|
| 19 | +{ |
| 20 | + "bbox": [ 5.5, 46, 8, 47.4 ], |
| 21 | + "time": { |
| 22 | + "gt": "2018-03-15T00:00:00.000Z", |
| 23 | + "lt": "2018-04-01T00:00:00.000Z" |
| 24 | + } |
| 25 | +} |
| 26 | +``` |
| 27 | + |
| 28 | +This tells the server to return all the catalog items it has that are from the second half of March, 2018 and |
| 29 | +that fall within this area: |
| 30 | + |
| 31 | + |
| 32 | + |
| 33 | +*map © OpenStreetMap contributors* |
| 34 | + |
| 35 | +The return format is a [GeoJSON](http://geojson.org) feature collection with features compliant with the |
| 36 | +[json spec]((../json-spec/json-spec.md) for STAC. It returns to a limit optionally requested by the client, and includes |
| 37 | +pageable links to iterate through any results past that limit. |
| 38 | + |
| 39 | +## Specification |
| 40 | + |
| 41 | +The definitive specification for STAC is the [OpenAPI](http://openapis.org) 3.0 yaml document. This is available |
| 42 | +in several forms. The most straightforward for an implementor new to STAC is the [STAC-standalone.yaml](STAC-standalone.yaml). |
| 43 | +This gives a complete service with the main STAC endpoint. See the [online documentation](https://app.swaggerhub.com/apis/cholmesgeo/STAC-standalone/0.4.0) for the api rendered interactively. |
| 44 | + |
| 45 | +An OpenAPI 2.0 (swagger) version will be available soon, which can be useful for autogenerating client and server code. |
| 46 | + |
| 47 | +##### Warning |
| 48 | + |
| 49 | +**The latest spec has not yet been fully validated by actual implementations. This will come soon, but if you |
| 50 | +are new to STAC and are trying to use the spec we recommend you jump on the [stac gitter](https://gitter.im/SpatioTemporal-Asset-Catalog/Lobby) |
| 51 | +to get help** |
| 52 | + |
| 53 | +### Filtering |
| 54 | + |
| 55 | +The core STAC API includes two filters - Bounding Box and time. All STAC Items require space and time, and thus any STAC |
| 56 | +client can expect to be able to filter on them. Most data will include additional data that users would like to query on, |
| 57 | +so there is a mechanism to also specify more filters. See the [Filtering](filters.md) document for additional information |
| 58 | +on the core filters as well as how to extend them. It is anticipated that 'profiles' for domains (like earth observation |
| 59 | +imagery) will require additional fields to query their common fields. |
| 60 | + |
| 61 | +### WFS 3.0 Integration |
| 62 | + |
| 63 | +At the [Ft Collins Sprint](https://github.com/radiantearth/community-sprints/tree/master/03072018-ft-collins-co) the |
| 64 | +decision was made to integrate STAC with the [WFS 3 specification](https://github.com/opengeospatial/WFS_FES), as |
| 65 | +they are quite similar in spirit and intention. It is anticipated that most STAC implementations will also implement |
| 66 | +WFS, and indeed most additional functionality that extends STAC will be done as WFS extensions. |
| 67 | + |
| 68 | +This folder thus also provides an [openapi fragment](STAC-fragment.yaml), as well as an [example service](https://app.swaggerhub.com/apis/cholmesgeo/STAC_WFS-example/0.4.0) ([yaml](WFS3core+STAC.yaml)) |
| 69 | +for those interested in what a server that implements both STAC and WFS would look like. Those interested in learning more |
| 70 | +can read the [deeper discussion of WFS integration](wfs-stac.md). |
| 71 | + |
| 72 | + |
| 73 | +### GET requests |
| 74 | + |
| 75 | +The POST endpoint is required for all STAC API implementations. The fields of the JSON object can also be used |
| 76 | +for a GET endpoint, which are included in the openapi specifications. The GET requests are designed to reflect the same |
| 77 | +fields as the POST fields, and are based on WFS 3 requests. It is recommended for implementations to implement both, but |
| 78 | +only POST is required. |
12 | 79 |
|
13 |
| -This will display the documentation and examples for the specification. You can also generate code for |
14 |
| -clients and servers in a variety of languages from the editor as well, so you can get a sense of how it |
15 |
| -will work. |
16 | 80 |
|
17 |
| -You can also use the yaml spec for code generation in a variety of tools. |
18 | 81 |
|
19 |
| -Once OpenAPI 3.0 has more tooling support this spec will be migrated to that version of OpenAPI. |
|
0 commit comments