-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: V4.0_WD01
-
Fix Version/s: CN01
-
Component/s: Repeatable Requests
-
Labels:None
-
Environment:
[Proposed]
-
Proposal:
Many backend systems will generate a key in response to a newly POSTed entity.
If a client sends a POST request to create an entity, and the OData service does create the entity, but the HTTP response to the client is lost, the client may be unsure as to whether or not the request succeeded. If the client repeats the request, it may result in duplicate information in the backend system.
Idempotence is especially important for clients which want to be able to do store-and-forward (e.g. offline enablement).
We've already implemented this proposal: http://help.sap.com/saphelp_gateway20sp06/helpdata/en/67/8b5dcd6a5c41789b27b46eb34a6a86/frameset.htm
Some additional clarification might be made in respect of change sets.
Can Repeatability be specified at change set level, or must it be applied to the individual requests within a change set?
Nice proposal document. However there is scant mention of whether if the original request had non-empty response content, whether the server (when it supports Repeatability) is REQUIRED to return the same content (payload) if the request is repeated. All I see is:
o Repeatability on PUT/PATCH is different from use of an etag in that repeated PUT/PATCH operations to the same resource will return success (or failure), possibly including a payload, versus a concurrency violation.
(What about payload for the result of POST, I wonder).
Also, even though the proposal is wider than OData, would we expect when this feature is used with OData that header names would begin with "odata." in accordance with other recent changes?