Open APIs

Expand all | Collapse all

414 Request to long

  • 1.  414 Request to long

    TM Forum Member
    Posted May 27, 2020 11:05
    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)
    ------------------------------


  • 2.  RE: 414 Request to long

    Posted May 29, 2020 08:18
    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
    ------------------------------



  • 3.  RE: 414 Request to long

    TM Forum Member
    Posted Jun 01, 2020 01:54
    Hi

    Sergey, you might want to reach out to your DT colleague @Alexis de Peufeilhoux, who has recently completed the updated TMF630 design guide​​lines.

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



  • 4.  RE: 414 Request to long

    TM Forum Member
    Posted Jun 02, 2020 02:51
    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)
    ------------------------------



  • 5.  RE: 414 Request to long

    TM Forum Member
    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.
    ------------------------------



  • 6.  RE: 414 Request to long

    TM Forum Member
    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)
    ------------------------------



  • 7.  RE: 414 Request to long

    TM Forum Member
    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.
    ------------------------------



  • 8.  RE: 414 Request to long

    TM Forum Member
    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)
    ------------------------------



  • 9.  RE: 414 Request to long

    TM Forum Member
    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.
    ------------------------------



  • 10.  RE: 414 Request to long

    TM Forum Member
    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)
    ------------------------------



  • 11.  RE: 414 Request to long

    TM Forum Member
    Posted Jun 05, 2020 10:40
    Yes :)

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