Jonathan,
Whould it better to change TMF648 to have "root" QuoteItem as separate resource?
To be able to POST /quote/{id}/quoteItem?
PS: I understand that changing TMF622 ProductOrder would impact lot of things (and for many activities you need the whole order anyway; e.g. preparation of OrchestrationPlan), but Quote API should be doable.
------------------------------
Peter Rajsky
CGI Information Systems and Management Consultants Inc.
------------------------------
Original Message:
Sent: Jul 09, 2023 05:15
From: Jonathan Goldberg
Subject: TMF648 Quote Management API - response message too big (contains all quote details)
Tricky one this, Zoran.
The standard POST response body is supposed to contain the entire entity. And as distinct from GET, where you can specify entity masking on the query string, POST doesn't have a query string in the contract. So ...
- If the web server, JSON mapper, etc. in your particular implementation of POST does support query string, you could use the same syntax as for GET. Of course this would be an extension behavior, not sanctioned by TMF
- You could use a dedicated Task resource (extension) to manage the creation, and this Task resource would include the Quote entity to be created, together with explicit instructions on how to mask the output entity.
- You could declare in your API implementation that you don't return the entire entity, only (say) the id/href/other essential properties in the POST return body. Anyone who wants more info would use GET with the returned id. Here also this would be an extension behavior, and it's possible you wouldn't pass the CTK in this case.
Presumably we will have the same problem with B2B ProductOrders (TMF622)?
------------------------------
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: Jun 20, 2023 09:58
From: Zoran Stojanovic
Subject: TMF648 Quote Management API - response message too big (contains all quote details)
We have been implementing the TMF648 Quote management API and noticed that in the vendor's implementation of this API for createQuote or patchQuote, we get far too big response that contains all the quote details. This makes the payload of the response for B2B quotes extremely big (> 4MB) which causes problems and limitations on the API consumer side.
Are there a known design pattern and implementation for this API to avoid this issue of too big response of Quote Management API?
------------------------------
Zoran Stojanovic
T-Mobile Netherlands BV
------------------------------