Repository navigation
Bulk Post - Is It Supported? #185
Description
I believe the future 3.0 pub/sub supports bulk create, and I was curious if part1+2 also support bulk create?
According to the wording of the redoc files it appears that its really just one resource per POST, then in the documentation file there is no direct reference to multiple resources for its POST that i could find (at least for observation, the main resource i am looking at)
Is this similar to UPDATE (where it's not in redoc) and a documentation oversight (or I clearly could have just missed something) and its assumed that all POST endpoints can take an array of resources?
Activity
EricLo-417 commentedon Jul 1, 2026
In addition to bulk/batch POST for observations (and really every resource). I think there is a good case for batch DELETE. Especially for observations which could have millions of observations.
Ideally it may make sense to DELETE using the same query params as GET. That way you can easily delete all observation from system X for example
alexrobin commentedon Jul 1, 2026
Hi, I agree that there are good use cases for batch POST/DELETE but there are several options to do it. So, rather than reinventing the wheel, the idea was to develop this jointly with the OGC API Feature or OGC API Common group instead of doing our own just for CS API (just like we inherited the transactional operations from OGC API Features part 4).
@Sam-Bolling @tipatterson-dev Are you aware of any discussion on the subject in other OGC WGs? I think this is a good topic to bring up at the OGC API session of the next OGC meeting. We could lead the work on this if nobody else does but I don't think we should do it without consulting the other API SWGs.
Sam-Bolling commentedon Jul 1, 2026
@alexrobin I will take it for action to find out if the other SWGs have made progress in this area that our effort can benefit from and/or if there are opportunities to collaborate.
Respectfully,
Sam
Sam-Bolling commentedon Jul 13, 2026
As follow-up to the action I accepted above, I reviewed the public workspaces of the OGC API Features, Common, EDR, and Records groups. OGC API Features currently has four published parts—Parts 1, 2, 3, and 5—while Part 4 remains in preparation for approval and Part 11 Atomic and Batch Transactions was introduced only as a proposal in April 2026. Features issue opengeospatial/ogcapi-features#1013 still identifies bulk creation as future work; Records defers complex transactions to eventual future work, and neither Common nor EDR currently provides a reusable bulk mutation model. The Part 11 proposal contains useful concepts, but its limited history, lack of review discussion, and early draft condition provide no indication that a published common solution is imminent.
Review of Connected Systems Parts 1 and 2 confirms that bulk operations are not currently interoperable: their normative Features Part 4 dependency covers individual-resource transactions, while the CS API OpenAPI material contains contradictory array definitions, endpoint descriptions, and unused batch schemas. The SWG could correct those artifacts and wait for Features Part 11, collaborate with the Features SWG to advance a common solution, or define an optional interim CS API capability that addresses immediate implementation needs while remaining compatible with the emerging common model. These options are not mutually exclusive, and the appropriate approach depends on the urgency of the CS API use cases and the expected progress of Part 11.
The principal immediate use case is efficient creation of many observations within a datastream, but any interoperable solution would need to define supported representations, atomic versus independent-item processing, ordered per-item results, validation, authorization, retry behavior, request-size limits, and synchronous or asynchronous execution. Bulk deletion is related but introduces additional questions about explicit identifiers versus query-based selection, the snapshot of resources being selected, authorization, partial failures, and safeguards against unintended deletion. This transaction problem is separate from the aggregate Pub/Sub notification discussed in #193.
I recommend that the SWG review these findings and options, including with the broader OGC API community at OGC Connect Cape Town, before deciding whether to wait for, collaborate on, or supplement the Features Part 11 work. @alexrobin, @autermann, @SpeckiJ, @tipatterson-dev, @EricLo-417, @pvretano, @tomkralidis, @ghobona , please review this recommendation and provide any comments before an upcoming SWG meeting so the group can consider the feedback and determine the appropriate path toward resolving and closing this issue.
Sam-Bolling commentedon Sep 3, 2026
Planned action from the OGC API – Connected Systems SWG bi-weekly meeting on July 23, 2026: @autermann will draft a paragraph explaining that bulk operations were considered but were not included because existing HTTP mechanisms can support efficient repeated requests over a persistent connection. The proposed text is intended as non-normative implementation guidance rather than a new bulk-operation requirement. Its appropriate location in the standard remains to be determined. Christian will post the draft for group review.