We likely will not need POST or DELETE endpoints because the PRDT backcountry database is not the source of truth for protected area information, rather it pulls the information nightly from the Data Register system.
There are two endpoints added with this change:
// bulk protected area put
PUT /protected-areas
// single protected area put
PUT /protected-areas/{orcs}
Both endpoints use nearly the same code, which is designed to handle an array of protected-area PUT requests. The singleton PUT endpoint casts the original request as an array of length 1.
In the dataUtils layer, some new functionality has been added that hopefully will speed up the process of adding PUT endpoints in the future. A generic API helper function to facilitate PUTs has been created. There is a README available in the layer folder but here is a brief summary of the helper function:
The helper function requires 3 arguments: tableName: the name of the table for DynamoDB to target
updateItems: a list of PUT requests, in the format outlined by the README
config: a helper configuration object in the format outlined by the README
The helper function takes the list of updateItem requests, and, using the rules outlined in the config object, creates a list of DynamoDB UpdateItem requests that can be sent to batchTransactData.
The benefit of this helper function is that if you format your PUT request properly, you can quickly spin up a PUT endpoint with predictable behaviour and minimal custom code. Additionally, all endpoints that use the helper function can be expected to perform the same way since they use the same source code. Finally, there is minimal custom code needed to spin up both singleton and batch PUT endpoints simultaneously.
Single Protected Area PUT
PUT /protected-areas/{orcs}
PUT body*:
{
'set': {'<fields to set>'},
'add': {'<fields to add>'},
'append': {'<fields to append>'},
'remove': ['<fields to remove>']
}
* see README for more information
Batch Protected Area PUT
PUT /protected-areas/
PUT body:
[
{
orcs: <orcs number>
actions: {
'set': {'<fields to set>'},
'add': {'<fields to add>'},
'append': {'<fields to append>'},
'remove': ['<fields to remove>']
}
},
{
...
}
]
NOTE: the actions argument for the bulk endpoint is the same as the request body for a single item put. The orcs number of the park must also be supplied for each item in the array.
The following fields are blacklisted for protected area PUTs (they cannot be updated):
Adding a PUT endpoint for Protected Areas.
We likely will not need POST or DELETE endpoints because the PRDT backcountry database is not the source of truth for protected area information, rather it pulls the information nightly from the Data Register system.
There are two endpoints added with this change:
Both endpoints use nearly the same code, which is designed to handle an array of protected-area PUT requests. The singleton PUT endpoint casts the original request as an array of length 1.
In the
dataUtilslayer, some new functionality has been added that hopefully will speed up the process of adding PUT endpoints in the future. A generic API helper function to facilitate PUTs has been created. There is a README available in the layer folder but here is a brief summary of the helper function:The helper function requires 3 arguments:
tableName: the name of the table for DynamoDB to targetupdateItems: a list of PUT requests, in the format outlined by the READMEconfig: a helper configuration object in the format outlined by the READMEThe helper function takes the list of
updateItemrequests, and, using the rules outlined in theconfigobject, creates a list of DynamoDB UpdateItem requests that can be sent tobatchTransactData.The benefit of this helper function is that if you format your PUT request properly, you can quickly spin up a PUT endpoint with predictable behaviour and minimal custom code. Additionally, all endpoints that use the helper function can be expected to perform the same way since they use the same source code. Finally, there is minimal custom code needed to spin up both singleton and batch PUT endpoints simultaneously.
Single Protected Area PUT
PUT body*:
* see README for more information
Batch Protected Area PUT
PUT body:
NOTE: the
actionsargument for the bulk endpoint is the same as the request body for a single item put. Theorcsnumber of the park must also be supplied for each item in the array.The following fields are blacklisted for protected area PUTs (they cannot be updated):