Hi Mahesh
In general, it is not obvious why GET operations would be asynchronous. In most software flows this would introduce unnecessary complications. TMF641 is no different in this respect - we can imagine some IT component for Service Order Management (an ODA component for instance) that exposes TMF641 and has database persistence for service orders. Why would GET be asynchronous - it's a simple retrieve or search in the database.
TMF640 (and it's Resource sister TMF702) are exceptional in this regard, as they are conceived as going to the actual network (e.g. hardware/firmware, perhaps via custom adaptor). In this specific case, it makes more sense to allow asynchronous operations even for GET, as described in the user guides for these two APIs.
Note that in v5 APIs we are looking at introducing a general Async API pattern that could in principle be applied to any API. Nevertheless each implementer of an API should carefully consider the impact of asynchronous operations and potential complexity that this causes for consumers.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------
Original Message:
Sent: Jul 12, 2023 07:35
From: Mahesh Choudhari
Subject: GET API for respective Open API like 640 or 641 etc. could be Sync or Async?
Dear Team,
Need your quick input / advise like GET call to retrieve specific service details can be implemented as sync response? Because as per TMF 630 design guidelines part1 GET call would be Async response like PATCH, POST etc.
In my use case if using 640 I have initially created network service Id and did activation etc. Later if consumer performing GET call for respective service ID then can it be provided as sync. response if its quick look up and fetch details. In case we need more details and taking time it would be aysnc response but Can we extend it as sync response?
Kindly advise. Thanks!!!
------------------------------
Mahesh Choudhari
UNSPECIFIED
------------------------------