414 Request to long

5. RE: 414 Request to long

Like

TM Forum Member

Jonathan Goldberg

Posted Jun 02, 2020 03:37

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

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)
------------------------------

6. RE: 414 Request to long

Like

TM Forum Member

Sergei Lukin

Posted Jun 02, 2020 03:46

This TASK resource will increase solution complexity, if we create such task - we should share state of Task accross all component instances.
(so we should persist task in db or use shared memory tools).

------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)
------------------------------

Original Message

Original Message:
Sent: Jun 02, 2020 03:37
From: Jonathan Goldberg
Subject: 414 Request to long

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)
------------------------------

7. RE: 414 Request to long

Like

TM Forum Member

Jonathan Goldberg

Posted Jun 02, 2020 08:59

Hi Sergey
Task resources do not need to be persisted, neither in memory nor on disk. If the task (a query in this case) is synchronous, then it's just a way of calling an API that doesn't fit conveniently into the REST CRUD verbs.
Since GET is not supposed to have a body (and I think this is REST/Swagger semantic, not just TMF guideline - quote from https://swagger.io/docs/specification/describing-request-body/

GET, DELETE and HEAD are no longer allowed to have request body because it does not have defined semantics as per RFC 7231.)

I don't see an alternative way of addressing your use case.

------------------------------
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

Original Message:
Sent: Jun 02, 2020 03:45
From: Sergey Lukin
Subject: 414 Request to long

This TASK resource will increase solution complexity, if we create such task - we should share state of Task accross all component instances.
(so we should persist task in db or use shared memory tools).

------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)

Original Message:
Sent: Jun 02, 2020 03:37
From: Jonathan Goldberg
Subject: 414 Request to long

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)
------------------------------

8. RE: 414 Request to long

Like

TM Forum Member

Sergei Lukin

Posted Jun 02, 2020 10:03

Thanks, it really helps if we can return result synchronously.
Just small question about naming,
is it ok to use verbs for such tasks? like POST /resourceInventory/resources/search (similar examples in TMF630 Task Resource Pattern)
or it is better use nouns? POST /resourceInventory/searchTasks

------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)
------------------------------

Original Message

Original Message:
Sent: Jun 02, 2020 08:58
From: Jonathan Goldberg
Subject: 414 Request to long

Hi Sergey
Task resources do not need to be persisted, neither in memory nor on disk. If the task (a query in this case) is synchronous, then it's just a way of calling an API that doesn't fit conveniently into the REST CRUD verbs.
Since GET is not supposed to have a body (and I think this is REST/Swagger semantic, not just TMF guideline - quote from https://swagger.io/docs/specification/describing-request-body/

GET, DELETE and HEAD are no longer allowed to have request body because it does not have defined semantics as per RFC 7231.)

I don't see an alternative way of addressing your use case.

------------------------------
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 03:45
From: Sergey Lukin
Subject: 414 Request to long

This TASK resource will increase solution complexity, if we create such task - we should share state of Task accross all component instances.
(so we should persist task in db or use shared memory tools).

------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)

Original Message:
Sent: Jun 02, 2020 03:37
From: Jonathan Goldberg
Subject: 414 Request to long

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)
------------------------------

9. RE: 414 Request to long

Like

TM Forum Member

Jonathan Goldberg

Posted Jun 03, 2020 01:27

To my best understanding, task resources should be a verbal phrase, such as CancelOrder, ClearAlarms, etc. So in your case I suggest RetrieveLogicalResourceList

------------------------------
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

Original Message:
Sent: Jun 02, 2020 10:03
From: Sergey Lukin
Subject: 414 Request to long

Thanks, it really helps if we can return result synchronously.
Just small question about naming,
is it ok to use verbs for such tasks? like POST /resourceInventory/resources/search (similar examples in TMF630 Task Resource Pattern)
or it is better use nouns? POST /resourceInventory/searchTasks

------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)

Original Message:
Sent: Jun 02, 2020 08:58
From: Jonathan Goldberg
Subject: 414 Request to long

Hi Sergey
Task resources do not need to be persisted, neither in memory nor on disk. If the task (a query in this case) is synchronous, then it's just a way of calling an API that doesn't fit conveniently into the REST CRUD verbs.
Since GET is not supposed to have a body (and I think this is REST/Swagger semantic, not just TMF guideline - quote from https://swagger.io/docs/specification/describing-request-body/

GET, DELETE and HEAD are no longer allowed to have request body because it does not have defined semantics as per RFC 7231.)

I don't see an alternative way of addressing your use case.

------------------------------
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 03:45
From: Sergey Lukin
Subject: 414 Request to long

This TASK resource will increase solution complexity, if we create such task - we should share state of Task accross all component instances.
(so we should persist task in db or use shared memory tools).

------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)

Original Message:
Sent: Jun 02, 2020 03:37
From: Jonathan Goldberg
Subject: 414 Request to long

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)
------------------------------

10. RE: 414 Request to long

Like

TM Forum Member

Sergei Lukin

Posted Jun 03, 2020 02:51

>>Names in URI (tasks, individual resources, etc.) MUST be camel case or lower case. (TMF630)
so better:
POST /resourceInventory/retrieveLogicalResourceList
isn't it?

------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)
------------------------------

Original Message

Original Message:
Sent: Jun 03, 2020 01:26
From: Jonathan Goldberg
Subject: 414 Request to long

To my best understanding, task resources should be a verbal phrase, such as CancelOrder, ClearAlarms, etc. So in your case I suggest RetrieveLogicalResourceList

------------------------------
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 10:03
From: Sergey Lukin
Subject: 414 Request to long

Thanks, it really helps if we can return result synchronously.
Just small question about naming,
is it ok to use verbs for such tasks? like POST /resourceInventory/resources/search (similar examples in TMF630 Task Resource Pattern)
or it is better use nouns? POST /resourceInventory/searchTasks

------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)

Original Message:
Sent: Jun 02, 2020 08:58
From: Jonathan Goldberg
Subject: 414 Request to long

Hi Sergey
Task resources do not need to be persisted, neither in memory nor on disk. If the task (a query in this case) is synchronous, then it's just a way of calling an API that doesn't fit conveniently into the REST CRUD verbs.
Since GET is not supposed to have a body (and I think this is REST/Swagger semantic, not just TMF guideline - quote from https://swagger.io/docs/specification/describing-request-body/

GET, DELETE and HEAD are no longer allowed to have request body because it does not have defined semantics as per RFC 7231.)

I don't see an alternative way of addressing your use case.

------------------------------
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 03:45
From: Sergey Lukin
Subject: 414 Request to long

This TASK resource will increase solution complexity, if we create such task - we should share state of Task accross all component instances.
(so we should persist task in db or use shared memory tools).

------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)

Original Message:
Sent: Jun 02, 2020 03:37
From: Jonathan Goldberg
Subject: 414 Request to long

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)
------------------------------

11. RE: 414 Request to long

Like

Alexis De Peufeilhoux

Posted Jun 05, 2020 10:40

Yes :)

------------------------------
Alexis de Peufeilhoux
Deutsche Telekom AG
------------------------------

Original Message

Original Message:
Sent: Jun 03, 2020 02:51
From: Sergey Lukin
Subject: 414 Request to long

>>Names in URI (tasks, individual resources, etc.) MUST be camel case or lower case. (TMF630)
so better:
POST /resourceInventory/retrieveLogicalResourceList
isn't it?

------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)

Original Message:
Sent: Jun 03, 2020 01:26
From: Jonathan Goldberg
Subject: 414 Request to long

To my best understanding, task resources should be a verbal phrase, such as CancelOrder, ClearAlarms, etc. So in your case I suggest RetrieveLogicalResourceList

------------------------------
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 10:03
From: Sergey Lukin
Subject: 414 Request to long

Thanks, it really helps if we can return result synchronously.
Just small question about naming,
is it ok to use verbs for such tasks? like POST /resourceInventory/resources/search (similar examples in TMF630 Task Resource Pattern)
or it is better use nouns? POST /resourceInventory/searchTasks

------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)

Original Message:
Sent: Jun 02, 2020 08:58
From: Jonathan Goldberg
Subject: 414 Request to long

Hi Sergey
Task resources do not need to be persisted, neither in memory nor on disk. If the task (a query in this case) is synchronous, then it's just a way of calling an API that doesn't fit conveniently into the REST CRUD verbs.
Since GET is not supposed to have a body (and I think this is REST/Swagger semantic, not just TMF guideline - quote from https://swagger.io/docs/specification/describing-request-body/

GET, DELETE and HEAD are no longer allowed to have request body because it does not have defined semantics as per RFC 7231.)

I don't see an alternative way of addressing your use case.

------------------------------
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 03:45
From: Sergey Lukin
Subject: 414 Request to long

This TASK resource will increase solution complexity, if we create such task - we should share state of Task accross all component instances.
(so we should persist task in db or use shared memory tools).

------------------------------
Sergey N Lukin
Deutsche Telekom (Tel-IT)

Original Message:
Sent: Jun 02, 2020 03:37
From: Jonathan Goldberg
Subject: 414 Request to long

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)
------------------------------

Open APIs