Release/1.3.0

[nikki-t]

[1.3.0]

Added

- Issue 186 - Implement API keys to control usage
- Issue 183 - Update documentation examples and provide a brief intro to the timeseries endpoint
- Issue 100 - Add option to 'compact' GeoJSON result into single feature
- Issue 101 - Add support for HTTP Accept header
- Issue 102 - Enable compression for API Responses

Changed

Deprecated

Removed

Fixed

- Issue 175 - Update all documentation to point to OPS instead of UAT

Security

[1.2.0]

Added

- Issue 124 - Log granule name on ingest
- Issue 155 - Log feature ids on database write
- Issue 21 - Create tutorial documentation
- Issue 142 - Add fields to support OPS monitoring and set up indexes to query on them

Changed

- Issue 161 - Remove obscure_data option from load data lambdas before OPS loading, add environment variable.

Deprecated

Removed

Fixed

- Issue 169 - 403 Error when accessing grnule through bulk load_data
- Issue 158 - Use Lambda role instead of EDL for s3 connection
- Issue 104 - Prevent nodes from being loaded into the reach table

Security

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[nikki-t]

UAT modification required:

1. REST API Terraform definition require a small modification to ensure the Lambda authorizer keys are used, added api_key_source = "AUTHORIZER".

Confirmed via UAT benchmark tests:

1. That the trusted user usage plan will throttle requests to return a '429: Too Many Requests' error response.
2. That the trusted user usage plan will return a 'Limit Exceeded' error response when the request quota is met.

[frankinspace]

Looks good to me. Once we release to ops we should point out the accept-header information to the working group and ask them to utilize that functionality so that the output is compact by default (they may need to update their clients).

[nikki-t]

@frankinspace - I completely forgot about the Elastic heartbeat ping requests the gateway gets every 15 seconds. They are currently included in the default usage plan and (if my math is correct) would generate ~172,800 requests per month.

Should we stick with including them in the default plan or should we provide them with their own API key?

[nikki-t]

We decided to allow the ping requests to be a part of the default usage plan and will explore the necessity of providing a separate key and possible usage plan in issue #192.