8.5 Create Error Handling
The SData provider MUST return one of the following HTTP status codes:
| Code | Description |
|---|---|
| 201 Created | POST was successful. Resource has been created. Response MUST contain a Location header with the URL of the created resource, plus the <entry> that was created. |
| 202 Accepted | An asynchronous POST was accepted. Or is in progress if this is a tracking request. A Location header with the tracking URL MUST be returned. The payload MUST be an <sdata:tracking> payload. See Tracking Payload section. |
| 400 Bad Request | Generic status for consumer side error. Client MUST modify the request before resubmitting. |
| 401 Unauthorized | Request requires user authentication. See Authentication section for details. |
| 403 Forbidden | Consumer is not authorized to create the resource. |
| 404 Not Found | One of the elements specified in the URL does not exist. For example, application name, contract name, or resource kind. |
| 409 Conflict | The resource cannot be created because of a conflict with existing resources. For example a violation on a unique index. If the service uses universally unique identifiers (UUIDs) generated by the consumer, it SHOULD NOT return a 409 error if it receives the same UUID twice. Instead, it SHOULD return a 201 success code. See note below. |
| 500 Internal Server Error | Serious provider error. Client SHOULD NOT retry the request. |
| 503 Service Unavailable | Transient provider error. Client MAY retry the request. The provider SHOULD include a Retry-After header in its response to indicate when the consumer MAY retry the request. |
When the service returns a 4xx or a 5xx status code, it SHOULD include an <sdata:diagnoses> payload with details about the error in its response. See Error Payload section for details.
If the service handles reliable POSTing at the application level (with UUIDs inside the payload, see Reliable Posting section), it SHOULD return the success response (201 status + Location + <entry>). If it receives a POST for an existing UUID on a resource that has been created but never modified, it SHOULD ignore the posted entry and return the entry as read from its data store. This guarantees the request is idempotent (safe to be called several times) from the consumer side.
SData providers MUST return errors as described above.