Hi Christophe,
Thanks for the reply.
Actually, my doubt was originated as per the contents of the TMF630 specification, where we see two flavors
(with examples) for the pagination:
From Document:
REST API Design Guidelines Part 1
TMF630 (Team Approved Date: 08-May-2020)
It's clear the offset + limit is the first choice but, at page 45, we have below request:
(..)
The following example shows how to use the Range header to iterate a collection of trouble
tickets.
The example assumes that 50 trouble tickets match a filtering criteria and that the maximum
amount of trouble tickets being retrieved by calls is set by default to 10.
REQUEST
|
GET /api/troubleTicket?dateTime.gt=2013-04-20&status=acknowledged
Accept-Range:items
Range:items=11-20
|
RESPONSE
|
206 Partial Content
Content-Type: application/json
Content-Range: items 11-20/50
[{
"id": "47",
"href": " /troubleTicketManagement/troubleTicket/47",
:
|
(..)
So, in this example, TMF is not using the offset+limit to control the number of returned items in a collection
but, the content-range pattern.
So, from my understanding the options are:
1) we assume that both are valid alternatives (as my original guess)
2) an update on the guideline (TMF630) is required (as per above example)
Regards,
Marcos.
------------------------------
Marcos Donato da Silva
Ericsson Inc.
------------------------------
Original Message:
Sent: Nov 17, 2020 02:12
From: Christophe MICHEL
Subject: Pagination: offset and limit
Hi,
1) Seems the current guideline is enforcing supporting pagination. I think this should be a challenged assertion, as pagination, like support for any pattern, is really to be implemented if there is some effective usage planned for it. This should be part of setting the design, always, but not enforced.
2) It is a MUST to align with the guidelines which especially means matching the reserved parameters and their semantic (minimal support means MUST support X-Total-Count in response header, offset + limit in query).
3) As per 2), answer is actually 'no'. The all idea of guidelines is for all to match the same pattern, not to support heterogeneous 'flavors'.
Summarizing: Pagination is currently stated as mamdatory (at least it should always be considered) and the guideline for its support is (only) as per pattern described in the guidelines (no other 'alternative').
Kind regards,
------------------------------
Christophe MICHEL
Amdocs Management Limited
Original Message:
Sent: Nov 16, 2020 08:56
From: Marcos Donato da Silva
Subject: Pagination: offset and limit
Hello,
I was checking the TMF630 around pagination and, I'm in doubt around these sentences:
1) Pagination is mandatory - Assumed answer is yes.
2) Pagination can be done with offset and limit or, must be done with offset and limit - Assumed answer is CAN.
3) Pagination can be done with content range as the pagination solution to the offset and limit - Assumed answer is YES.
Summarizing: Given that pagination is mandatory, I can choose between the "offset" or "content range" solution for pagination.
Is this correct?
------------------------------
Marcos Donato da Silva
Ericsson Inc.
Original Message:
Sent: Nov 22, 2018 06:04
From: Vance Shipley
Subject: Pagination: offset and limit
Pagination is done using RFC7233 range request HTTP headers where the unit is "items".
This is described in Design Guidelines for REST APIs - Part 1 in the section Query Resources with Attribute Filtering and Iterators.
------------------------------
Vance Shipley
SigScale Global Inc.
Original Message:
Sent: Nov 21, 2018 09:56
From: Ibrahima Gaye
Subject: Pagination: offset and limit
Hello dears,
i am new to TMF APIs and new to this discussion group,
so sorry i my questions seems silly :)
1. How can i include Pagination: an offset and a limit to the queries; the result will be from record at 'offset' to record at 'offset+limit'?
2. In product ordering : I have an order with many order items, the order items don't have the same start-time (aka activation date) how can i include that parameter ?
3. API for Bill Creation: Does it exist an API to create dynamically a bill (not using order apis) ? (Call the API and parameters will be the Bill details)
4. Payment Plan: Is it possible to supply the payment plan dynamically ? (to give the payment plan agreed with the customer when making the order)
Any help/hint/link will be highly appreciated
Thank you very much
Best regard
------------------------------
Ibrahima Gaye
ZTE Corporation
------------------------------