Hi Erlina,
Firts of all, Well summarized Vance Shipley! That is the essence and the references to TMForum recommendations are excellent. If you are working against APIs based in TMForum that should be your guideline.
You got many perspectives on this matter so far, and all contribute to a given extent (mostly because we do not quite understand your end goal at this moment).
Assuming you are working with Entity manipulation against a system that offers Restful APIs, you should first check the standard in RFC2626 for more details on when to use each HTTP method to manipulate your data elements. That is the more formal approach (but valuable since you get familiar with the idea behind most of the answers you see here).
When faced with this type of questions, normally the assessment is simple, and based in the following premises:
- POST will CREATE a new entity with the attributes you sent, and in return, it gives you whatever response you agreed upon and in addition, normally a unique identifier for that entity (usually referred to as ID).
- PUT and other operations (including PATCH) would normally be used for MODIFYING an existing entity in a collection. they would normally contain an ID right in the input, (as they assume we will take action on a targeted entity uniquely identifiable by ID).
Assuming you are working under the concepts listed above, if what you are looking for is to reduce the response time, you could work with the somewhat Static or Predictable portion of the response and make it statically mapped from request to response or even cache some segment that may be somewhat constant, based in simple lookup keys. You would still need to keep the elements that vary (the ID for instance) as dynamic elements of the response.
The underlying question is: What are you trying to achieve with what you refer to as idempotency? (POST or any CREATE API will not be idempotent anyways). so you probably have other targets. Let us know and I bet you'll receive more preise recommendations from the community.
Looking from another angle: Assume you have another type of "unique id" for the REQUEST itself (and not for the order), you could make a FAST response pattern that returns an acknowledgment the order has been received but is in process. With that approach you could actually have a POST message, that will not return the ID to you (and that can fail) but that will quickly respond to you that the request have been accepted. You would need to couple that with some sort of GET API and some attribute that would allow you to understand that the entity creation already completed (and would then return the ID to you).
That pattern can be useful in scenarios where the requirements to get an ID are too strict and may push the execution time of the post request too far away. In that case it may be better to have a POST returning quicker and a Polling or Call Back mechanism to retrieve the id of the created entity later on.
Again, a lot of guessing. Let us know what you want to achieve and we may be able to help more. * This is an area of constant discussions and there is no absolute right approach here, but good judgment on which approach to use according to your application needs.
------------------------------
Raphael do Amaral Raymundo
Ericsson Inc.
------------------------------
Original Message:
Sent: Oct 14, 2019 02:48
From: Erlina Hennies
Subject: ServiceOrderingManagement_POST Idempotency
Dear all,
I sought for help about the ServiceOrderingManagement in regards to Idempotency using operation. Currently we are using POST.
Idempotence is when a service is accessed several times with identical access parameters, the same return value is always returned as the very first time it was accessed.
POST method is usually used to create a new data record. Will this does not satisfy the requirement of idempotence? If not which http(s) methods (e.g., GET, PUT, DELETE) will fulfill this requirement by definition?
Thanks in advance for your prompt answer!
Cheers
Erlina
#TMForumGeneral
------------------------------
Erlina Hennies
Deutsche Telekom AG
------------------------------