Deprecate /bulk_items

[jonhealy1]

Related Issue(s):

• Add bulk_items endpoint stac-api-extensions/transaction#16

Description:

• Deprecated BulkTransactionExtension (POST /collections/{collection_id}/bulk_items). Use TransactionExtension instead, which supports ItemCollection payloads on POST /collections/{collection_id}/items.

PR Checklist:

• pre-commit hooks pass locally
• Tests pass (run make test)
• Documentation has been updated to reflect changes, if applicable, and docs build successfully (run make docs)
• Changes are added to the CHANGELOG.

[vincentsarago]

does the TransactionExtension allow do to upsert? is the idea to use PUT to create or update an item?

I'm also not found of the response from POST /collections/collection_id/items which doesn't indicate clearly if all or some items were not created (when multi Items where passed as input).

As mentioned by stac-api-extensions/transaction#16 (review) the TransactionExtension already takes some freedom from the OGC specs by allowing FeatureCollection (Items) instead of single Feature (Item). This might lead to issues when the OGC Features Part 4 is released, meaning the our transactionExtension won't be compliant.

I know I said I was fine with the change in stac-api-extensions/transaction#16 but I'm having second thoughts 🙈

IMO, one possible path we could follow is:

• stop overloading the /items endpoint and remove ItemCollection as a possible input
• keep /bulk_items and update the spec (as originally planned)

If we remove the bulk_items extension and in the future decide that our transaction extension should follow the OGC Feature Part 4 we will be stuck.

[jonhealy1]

I opened this issue in the transaction extension repo and @ahmed-hassan19 is going to make a pr I think to try to clear some of this up.

I liked the idea of getting rid of one of the ways to post bulk items. I think not overloading the /items endpoint would be nice.

We are just deprecating here I guess and we could undeprecate later. Or we could just leave this pr open for a while and try to figure out what works best.

Maybe we keep both routes and wait to see what happens with OGC Features Part 4?