Javascript Question posted in
A very good W3school tutorial can be found here.

Javascript – In a RESTful API how should you handle optional query parameters

I’m currently dealing with a .net API that aims to be RESTful. One of the endpoints I’m working with has two optional query parameters. The following usage is allowed:

/endpoint/search
/endpoint/search?from=01/02/23
/endpoint/search?from=01/02/23&to=01/03/23

This endpoint however returns a 400 when you do not provide a value for these optional query params but the keys still exist. Since I primarily work in JS, having the query params either not exist or have a value of undefined are realistically the same thing this seems odd to me that it would return a 400.

I.e.

/endpoint/search?from=undefined&to=undefined // 400 response

I’ve tried to scour the internet for an answer. I’ve looked into OpenAPI specification and the REST rfc but I can’t find any relevant passages. I’m of the opinion this is making an endpoint overly restrictive and it should handle undefined as a value. What is the correct approach as per spec if possible?

Tags:

2

Answers


  1. 0

    If the API allows values, then I would strongly expect the values to have to match the expected values or not be present at all

    In your example the value is not undefined. It is the string "undefined" and the api expects d{1,2}/d{1,2}/d{1,2} or no parameter at all or it will correctly give status 400 Bad Request or similar

    If your description of the rest endpoint is correct, then I would code it like this (perhaps with sanity check that if you have to, you must also have from)

    const url = new URL(`https://endpoint.com/endpoint/search`);
let from='01/02/23', to;
if (from) url.searchParams.set('from', from)
if (to) url.searchParams.set('to', to)
console.log(url.toString())
    Login or Signup to reply.
  2. 0

    What is the correct approach as per spec if possible?

    I don’t like your odds of finding a spec.

    You certainly shouldn’t be able to find a credible REST or HTTP reference, for this reason: HTTP defines the semantics of messages about resources, but doesn’t actually constraint resource design, resource identifier design, or the semantics of either of these.

    From the perspective of HTTP, the target uri is a whole indivisible thing. General purpose HTTP components are not supposed to be parsing the URI to derive information that will change local behaviors.

    (This was something of a problem for a time with web caches, which had some unfortunate ideas about what it meant for a URI to include a query part.)

    having the query params either not exist or have a value of undefined are realistically the same thing

    From the perspective of HTTP, these aren’t the same thing at all. See RFC 3986 Normalization and Comparison to get a sense for what kinds of assumptions general purpose components are expected to make.

    What you are really asking for here is a standard that constrains how resources are identified in models; does the existence of a resource identified by /endpoint/search?from=01/02/23&to=01/03/23 mean that there also rfc:2119:SHOULD be a resource identified by /endpoint/search?from=undefined&to=undefined, and if so what representations should it have?

    You might be able to find some design guidelines shared by specific communities; for example, I wouldn’t be shocked there is a guideline that a lot of Rails projects opt into, or guidelines shared within the OpenAPI community, in much the same way that communities might share a coding style guide.

    That said, you should probably make sure that you are familiar with Postel’s Law / The Robustness Principle, and it’s consequences as experienced on the world wide web, before getting deeply invested in a stance for whether a resource model should or should not support this particular edge case.

    All that said, HTTP 404 would probably be a better choice than HTTP 400 for responding when the URI in the request doesn’t actually match a resource on the server, because general purpose web caches will be able to re-use the 404 response when appropriate.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search