Open APIs

 View Only
  • 1.  URL UNsafe characters in query parameters

    TM Forum Member
    Posted Nov 22, 2021 09:41
    Hi All,

    We have a scenario where the query parameters have mobile numbers  in E164 format. In E164 format, mobile numbers to be prefixed with "+" character which is to be URL converted before sending the request. As per the REST best practices, query parameters should not have url unsafe charcters. How to handle such requests. Converting GET call to POST call is one option. Passing the parameters as header parameters is another option which is again  not a a common practice (so, less developer friendly).  Do we have any other option? How to manage such requests?

    Same question is applicable when we more number of query parmeters (more than 10). Is it OK to accept 10 query parameters or should the API be converted to POST call or is there any other option?

    Best regard,
    Kalpana

    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------


  • 2.  RE: URL UNsafe characters in query parameters

    TM Forum Member
    Posted Nov 22, 2021 10:51
    Maybe I missed something, but why can't you url-encode the characters such as + , which would become %2B , and is thus safe.
    POST is not really a good idea for a query, although if you had no alternative you could construct a task resource that executes the query.

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



  • 3.  RE: URL UNsafe characters in query parameters

    TM Forum Member
    Posted Nov 23, 2021 04:50
    Thank you Jonathan. Got clariity on the way to handle E164 format.

    Is there any recommendation on the number of query parameters that can be accepted. For example if it is more than N number of query parameters, then better to convert to a post call. What is the value of N.

    Best regards,
    Kalpana

    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------



  • 4.  RE: URL UNsafe characters in query parameters

    TM Forum Member
    Posted Nov 23, 2021 05:37
    Hi
    I don't think the number of query params is relevant here. The primary difficulty is the length of the URL string that is allowed by all the software elements in the calling chain (web server, API gateway, etc.). The query string, with all its (encoded) params, is just that, a string.
    You need to investigate the URL length limitations that you might have for internal and external consumers of your API, and plan accordingly.
    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.
    ------------------------------



  • 5.  RE: URL UNsafe characters in query parameters

    TM Forum Member
    Posted Nov 23, 2021 09:39
    Thank you Jonathan. It helps.

    Best regards,
    Kalpana

    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------



  • 6.  RE: URL UNsafe characters in query parameters

    TM Forum Member
    Posted Nov 24, 2021 01:51
    On Nov 23, 2021 04:49 @Kalpana HV wrote:
    |  Is there any recommendation on the number of query parameters that can be accepted. For example if it is more than N number of query parameters, then better to convert to a post call. What is the value of N.

    There is not, the IETF RFCs provide no limit to the length of a resource path. Your systems implementations (i.e. Apache) probably do however that limit should be quite high.  In any event it wouldn't be an issue of N query parameters but the total length of the HTTP request line.



    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------