OK, I understand, I had thought your problem was with
fields, but now I see it is with
filter.
Perhaps consider creating a dedicated task resource to do the complex query - this is basically a workaround that allows you to do the equivalent of a GET with a request body.
You would construct a task REST resource with an input section having an array of IDs, and an output section having an array of resources to be returned.
Then you would POST the task to execute the query.
Hope it helps
------------------------------
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 02, 2020 02:51
From: Sergey Lukin
Subject: 414 Request to long
One possible workaround would be for you to define some fixed field masks for known use cases. Such masks would aggregate long lists of field names as a single label.
Do you really have a situation when you would accept arbitrary lists of fields?
It is not helps us, for example we have "list of ids" as part of filter
------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)
Original Message:
Sent: Jun 01, 2020 01:53
From: Jonathan Goldberg
Subject: 414 Request to long
Hi
Sergey, you might want to reach out to your DT colleague @Alexis De Peufeilhoux, who has recently completed the updated TMF630 design guidelines.
One possible workaround would be for you to define some fixed field masks for known use cases. Such masks would aggregate long lists of field names as a single label.
Do you really have a situation when you would accept arbitrary lists of fields?
Hope it helps
------------------------------
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: May 29, 2020 08:18
From: Pieter Pabst
Subject: 414 Request to long
Although it doesn't help you in relation to TMF, it sounds GrapQL is a more suitable protocol for your needs in this case (which yes uses a POST). We opted to support those in addition to TMF compliant (REST based) OpenAPI's for use-cases like these.
Only way I'd see to resolve this other than changing your middleware thresholds (which might conflict with security policies), is to add POST method as you suggested. But to pass the CTK / compliance you'll have to keep a GET method.
------------------------------
Pieter Pabst
Dynacommerce
Original Message:
Sent: May 27, 2020 11:04
From: Sergey Lukin
Subject: 414 Request to long
HI all,
I need advice how you solve this issue:
in most GET queries TMF Open API allow to implemenet filtering like here:
GET /logicalResource?fields=...&{filtering}
In our case filtering is too complex and not fit with maxumum size of URL (in most webservers it is not more then 8096chars), so consumer recieve HTTP error "414 URL too long."
How you handle this situation?
I know at least two options:
1) try to change max size of URLs in our webservers/middleware (it helps for long time, but not solve problem)
2) use POST inseted GET for sending so complex filtering (but it is contradict with TMF Open API reccomendation)
------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)
------------------------------