|
| 1 | +=== Batch Mode |
| 2 | + |
| 3 | +This standard defines a simple batch protocol so that large numbers of resources can be added, replaced and deleted in a more efficient manner. |
| 4 | + |
| 5 | +This section provides general requirements for the batch mode as well as some request/response payload requirements for the batch operations. For BATCH CREATE and BATCH REPLACE operations, each encoding requirements class must define the payload to use for batching resource representations. |
| 6 | + |
| 7 | +[requirement,model=ogc] |
| 8 | +==== |
| 9 | +[%metadata] |
| 10 | +identifier:: /req/create-replace-delete/batch-mode |
| 11 | +
|
| 12 | +The server SHALL support batch mode on all resource collection endpoints that support create, replace and delete operations on resources. |
| 13 | +==== |
| 14 | + |
| 15 | + |
| 16 | +==== Requirements common to all batch operations |
| 17 | + |
| 18 | +A fully successful execution of a batch operation is always reported as a response with HTTP status code 200 and includes a reponse body. |
| 19 | + |
| 20 | +[requirement,model=ogc] |
| 21 | +==== |
| 22 | +[%metadata] |
| 23 | +identifier:: /req/create-replace-delete/batch-mode-success |
| 24 | +
|
| 25 | +conditions:: No error occurs during individual resource operations. |
| 26 | +
|
| 27 | +part:: The server SHALL respond with an HTTP status code 200. |
| 28 | +
|
| 29 | +part:: The response body SHALL be valid according to the JSON schema {batch-response-schema}. |
| 30 | +==== |
| 31 | + |
| 32 | +It is up to the server implementation to reject the entire batch request if some of the operations fail, or to allow partial processing. If the server rejects the entire request, it must indicate this with a single error status code, and must also guarantee that any applied changes are rolled back (processed as an atomic transaction). |
| 33 | + |
| 34 | +In all cases, the response body provides detailed status for each individual resource operation. |
| 35 | + |
| 36 | +[requirement,model=ogc] |
| 37 | +==== |
| 38 | +[%metadata] |
| 39 | +identifier:: /req/create-replace-delete/batch-mode-partial |
| 40 | +
|
| 41 | +conditions:: |
| 42 | + - Some errors occur during individual resource operations. |
| 43 | + - The server allows for partial processing. |
| 44 | +
|
| 45 | +part:: The server SHALL respond with an HTTP status code 200. |
| 46 | +
|
| 47 | +part:: The response body SHALL be valid according to the JSON schema {batch-response-schema}. |
| 48 | +==== |
| 49 | + |
| 50 | +[requirement,model=ogc] |
| 51 | +==== |
| 52 | +[%metadata] |
| 53 | +identifier:: /req/create-replace-delete/batch-mode-atomic |
| 54 | +
|
| 55 | +conditions:: |
| 56 | + - Some errors occur during individual resource operations. |
| 57 | + - The server rejects entire request. |
| 58 | +
|
| 59 | +part:: The server SHALL respond with an HTTP status code greater or equal to 400 (i.e. either a client error or server error status code). |
| 60 | +
|
| 61 | +part:: All applied changes SHALL be rolled back by the server. |
| 62 | +
|
| 63 | +part:: The server MAY include a response body, in which case the response body SHALL be valid according to the JSON schema {batch-response-schema-ref}. |
| 64 | +==== |
| 65 | + |
| 66 | + |
| 67 | +==== Batch Create |
| 68 | + |
| 69 | +===== Operation |
| 70 | + |
| 71 | +[requirement,model=ogc] |
| 72 | +==== |
| 73 | +[%metadata] |
| 74 | +identifier:: /req/create-replace-delete/batch-create-op |
| 75 | +
|
| 76 | +The BATCH CREATE operation SHALL be implemented as an HTTP POST request on the resource collection where the resources are to be added. |
| 77 | +==== |
| 78 | + |
| 79 | +===== Request Body |
| 80 | + |
| 81 | +[requirement,model=ogc] |
| 82 | +==== |
| 83 | +[%metadata] |
| 84 | +identifier:: /req/create-replace-delete/batch-create-request |
| 85 | +
|
| 86 | +part:: The body of the POST request SHALL contain the representations of the new resources to be added to the collection. |
| 87 | +
|
| 88 | +part:: Each resource representation SHALL include an `id` that will be used to identify the resource in the batch response. The server MAY generate a new `id` for the resource. |
| 89 | +
|
| 90 | +part:: The `Content-Type` header SHALL be set to a media type that defines a proper batching format. |
| 91 | +==== |
| 92 | + |
| 93 | +===== Response |
| 94 | + |
| 95 | +[requirement,model=ogc] |
| 96 | +==== |
| 97 | +[%metadata] |
| 98 | +identifier:: /req/create-replace-delete/batch-create-response |
| 99 | +
|
| 100 | +conditions:: The request is successful or partially successful |
| 101 | +
|
| 102 | +part:: The response body SHALL be valid according to the JSON schema {batch-response-schema}. |
| 103 | +
|
| 104 | +part:: For each resource included in the request, the response SHALL contain exactly one JSON object with the following data: |
| 105 | + - The `id` attribute SHALL contain the value of the `id` of the resource as provided in the request (not the id eventually generated by the server). |
| 106 | + - The `status` attribute SHALL contain the HTTP status code that would have been returned if the resource had been added individually using a CREATE operation. |
| 107 | + - The `location` attribute SHALL contain the URL of the newly added resource if successful |
| 108 | + - The `error` attribute MAY contain an error message describing why the operation failed for this resource. |
| 109 | +==== |
| 110 | + |
| 111 | + |
| 112 | +==== Batch Replace |
| 113 | + |
| 114 | +===== Operation |
| 115 | + |
| 116 | +[requirement,model=ogc] |
| 117 | +==== |
| 118 | +[%metadata] |
| 119 | +identifier:: /req/create-replace-delete/batch-replace-op |
| 120 | +
|
| 121 | +The BATCH REPLACE operation SHALL be implemented as an HTTP POST request on the sub-resource `/replace` of the resource collection that contains the resources to be replaced (e.g. `{api_root}/systems/replace`). |
| 122 | +==== |
| 123 | + |
| 124 | +===== Request Body |
| 125 | + |
| 126 | +[requirement,model=ogc] |
| 127 | +==== |
| 128 | +[%metadata] |
| 129 | +identifier:: /req/create-replace-delete/batch-replace-request |
| 130 | +
|
| 131 | +part:: The body of the POST request SHALL contain the new representations of the resources to be replaced in the collection. |
| 132 | +
|
| 133 | +part:: Each resource representation in the list SHALL contain the `id` of an existing resource to be replaced. |
| 134 | +
|
| 135 | +part:: The `Content-Type` header SHALL be set to a media type that defines a proper batching format. |
| 136 | +==== |
| 137 | + |
| 138 | +===== Response |
| 139 | + |
| 140 | +[requirement,model=ogc] |
| 141 | +==== |
| 142 | +[%metadata] |
| 143 | +identifier:: /req/create-replace-delete/batch-replace-response |
| 144 | +
|
| 145 | +conditions:: The request is successful or partially successful |
| 146 | +
|
| 147 | +part:: The response body SHALL be valid according to the JSON schema {batch-response-schema}. |
| 148 | +
|
| 149 | +part:: For each resource included in the request, the response SHALL contain exactly one JSON object with the following data: |
| 150 | + - The `id` attribute SHALL contain the value of the `id` of the resource as provided in the request. |
| 151 | + - The `status` attribute SHALL contain the HTTP status code that would have been returned if the resource had been replaced individually using a REPLACE operation. |
| 152 | + - The `error` attribute MAY contain an error message describing why the operation failed for this resource. |
| 153 | +==== |
| 154 | + |
| 155 | + |
| 156 | +==== Batch Delete |
| 157 | + |
| 158 | +===== Operation |
| 159 | + |
| 160 | +[requirement,model=ogc] |
| 161 | +==== |
| 162 | +[%metadata] |
| 163 | +identifier:: /req/create-replace-delete/batch-delete-op |
| 164 | +
|
| 165 | +The server SHALL implement the BATCH DELETE request by accepting a POST request on the sub-resource `/delete` on the resource collection that contains the resources to be deleted (e.g. `{api_root}/systems/delete`). |
| 166 | +==== |
| 167 | + |
| 168 | +===== Request Body |
| 169 | + |
| 170 | +[requirement,model=ogc] |
| 171 | +==== |
| 172 | +[%metadata] |
| 173 | +identifier:: /req/create-replace-delete/batch-delete-request |
| 174 | +
|
| 175 | +part:: The `Content-Type` header SHALL be set to `application/json`. |
| 176 | +part:: The body of the request SHALL be valid against the JSON schema {batch-delete-schema}. |
| 177 | +==== |
| 178 | + |
| 179 | +===== Response |
| 180 | + |
| 181 | +The server must generate the response as specified in the "Error Handling" section. |
| 182 | + |
| 183 | +[requirement,model=ogc] |
| 184 | +==== |
| 185 | +[%metadata] |
| 186 | +identifier:: /req/create-replace-delete/batch-delete-response |
| 187 | +
|
| 188 | +conditions:: The request is successful or partially successful |
| 189 | +
|
| 190 | +part:: The response body SHALL be valid according to the JSON schema {batch-response-schema}. |
| 191 | +
|
| 192 | +part:: For each resource included in the request, the response SHALL contain exactly one JSON object with the following data: |
| 193 | + - The `id` attribute SHALL contain the value of the `id` of the resource as provided in the request. |
| 194 | + - The `status` attribute SHALL contain the HTTP status code that would have been returned if the resource had been deleted individually using a DELETE operation. |
| 195 | + - The `error` attribute MAY contain an error message describing why the operation failed for this resource. |
| 196 | +==== |
| 197 | + |
| 198 | + |
| 199 | +==== Batch Update |
| 200 | + |
| 201 | +===== Operation |
| 202 | + |
| 203 | +[requirement,model=ogc] |
| 204 | +==== |
| 205 | +[%metadata] |
| 206 | +identifier:: /req/resource-update/batch-update-op |
| 207 | +
|
| 208 | +The BATCH UPDATE operation SHALL be implemented as an HTTP PATCH request on the resource collection that contains the resources to be updated. |
| 209 | +==== |
| 210 | + |
| 211 | +===== Request Body |
| 212 | + |
| 213 | +[requirement,model=ogc] |
| 214 | +==== |
| 215 | +[%metadata] |
| 216 | +identifier:: /req/resource-update/batch-update-request |
| 217 | +
|
| 218 | +part:: The URL of the PATCH request SHALL identify the representation to be patched. |
| 219 | +
|
| 220 | +part:: The body of the PATCH request SHALL contain a list of change instructions for each resource to be updated in the collection. |
| 221 | +
|
| 222 | +part:: Each item in the list SHALL contain the `id` of an existing resource to be updated. |
| 223 | +
|
| 224 | +part:: The `Content-Type` header SHALL be set to a media type that defines a proper patch format (e.g. JSON Patch, JSON Merge-Patch). |
| 225 | +==== |
| 226 | + |
| 227 | +===== Response |
| 228 | + |
| 229 | +[requirement,model=ogc] |
| 230 | +==== |
| 231 | +[%metadata] |
| 232 | +identifier:: /req/resource-update/batch-update-response |
| 233 | +
|
| 234 | +conditions:: The request is successful or partially successful |
| 235 | +
|
| 236 | +part:: The response body SHALL be valid according to the JSON schema {batch-response-schema}. |
| 237 | +
|
| 238 | +part:: For each resource patch included in the request, the response SHALL contain exactly one JSON object with the following data: |
| 239 | + - The `id` attribute SHALL contain the value of the `id` of the resource as provided in the request. |
| 240 | + - The `status` attribute SHALL contain the HTTP status code that would have been returned if the resource had been added individually using a REPLACE operation. |
| 241 | + - The `error` attribute MAY contain an error message describing why the operation failed for this resource. |
| 242 | +==== |
| 243 | + |
| 244 | + |
| 245 | + |
| 246 | +==== Optimistic Locking |
| 247 | + |
| 248 | +Only the "Optimistic locking using timestamps" method defined in {ogcapi-features-4} can be used when replacing resources using batch mode. |
| 249 | + |
| 250 | +In this case, the value of the `If-Unmodified-Since` header is compared to the last-modified timestamp of each modified resource. |
| 251 | + |
| 252 | + |
| 253 | + |
| 254 | +[[clause-geojson-batch]] |
| 255 | +==== Batch Mode |
| 256 | + |
| 257 | +[requirement,model=ogc] |
| 258 | +==== |
| 259 | +[%metadata] |
| 260 | +identifier:: /req/geojson/batch-format |
| 261 | +
|
| 262 | +conditions:: The server implements <<clause-resource-crd,/req/create-replace-delete>>. |
| 263 | +
|
| 264 | +A BATCH CREATE or BATCH REPLACE request body SHALL be a valid GeoJSON `FeatureCollection` document. |
| 265 | +==== |
| 266 | + |
| 267 | + |
| 268 | + |
| 269 | + |
| 270 | +[[clause-sensorml-batch]] |
| 271 | +==== Batch Mode |
| 272 | + |
| 273 | +Multiple features can be added using the SensorML JSON format when wrapped into a collection object. |
| 274 | + |
| 275 | +[requirement,model=ogc] |
| 276 | +==== |
| 277 | +[%metadata] |
| 278 | +identifier:: /req/sensorml/batch-format |
| 279 | +
|
| 280 | +conditions:: The server implements <<clause-resource-crd,/req/create-replace-delete>>. |
| 281 | +
|
| 282 | +part:: A BATCH CREATE or BATCH REPLACE request SHALL have a `Content-Type` header with value `{sensorml-json-mediatype}` |
| 283 | +
|
| 284 | +part:: A BATCH CREATE or BATCH REPLACE request body SHALL be valid against one of the following schemas: |
| 285 | +
|
| 286 | +- {sensorml-system-collection-schema} |
| 287 | +- {sensorml-procedure-collection-schema} |
| 288 | +- {sensorml-deployment-collection-schema} |
| 289 | +- {sensorml-property-collection-schema} |
| 290 | +==== |
| 291 | + |
| 292 | + |
| 293 | + |
0 commit comments