REST api that accepts a list of IDS

[Prasad Katti]

Hi All,

I have a requirement where I need to implement a GET API with an array of IDs as input. since this is a GET the ids would be part of query parameters.

as an example, assuming i have a user resource.

some alternatives would be [based on what I have gathered reading stuff on the internet]

1. GET /user/?ids=1,2,3,4

2. GET /user/?ids=1&ids=2&ids=3

I wanted to know couple of things.

Options 1 and 2 are feasible if we have a handful of Ids. in case there are a lot of IDs, would it be better to design at as POST API with the ids going as part of body?

regards,

Prasad

[Prasad Katti]

correction. forgot the pluralization.

1. GET /users/?ids=1,2,3,4
2. GET /users/?ids=1&ids=2&ids=3

regards

Prasad

[Chamal Nanayakkara]

If your IDs are in sequence (as they seem to be from your examples), you could treat them as a range and get the lower bound and upper bound values as query string parameters:

• GET /users?lowerboundid=1&upperboundid=4

Regards,

Chamal

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[sune jakobsson]

What are you trying to accomplish? The "GET" overhead, is almost ignorable, so why are you not doing a call pr ID, please explain?

Sune

[Jørn Wildt]

> The "GET" overhead, is almost ignorable, so why are you not doing a call pr ID, please explain?

Without knowing anything about the original problem, I think it is fair to say that GET does have its share of overhead in terms of latency - compare looking up N users by 1 single HTTP request to looking up N users by N requests: with about 100 users and a latency of 50 ms you go from 50 ms (plus payload) to at least 5 sec user waiting time. I believe it is a rather common scenario to fetch lists in batches.

> Options 1 and 2 are feasible if we have a handful of Ids. in case there are a lot of IDs, would it be better to design at as POST API with the ids going as part of body?

Yes.

You can let the API handle both - that should not be such a big code overhead. Then let the client decide whether to do GET or POST depending on the amount of IDs.

But why not always do POST? Well, there can be some caching issues - GET can be cached but I am not so sure about POST.

If caching is not an issue and you really expcect LARGE numbers of IDs then use POST.

/Jørn

[sune jakobsson]

Yes, I agree, but, if there is caching in-between, using a GET pr id will most likely be more efficient, but it also depends on the result that the API returns.

Sune

[Eric Stein]

On Thursday, May 26, 2016 at 7:43:52 AM UTC, Jørn Wildt wrote:

Without knowing anything about the original problem, I think it is fair to say that GET does have its share of overhead in terms of latency - compare looking up N users by 1 single HTTP request to looking up N users by N requests: with about 100 users and a latency of 50 ms you go from 50 ms (plus payload) to at least 5 sec user waiting time. I believe it is a rather common scenario to fetch lists in batches.

That's only true if the requests are made synchronously. If they're made asynchronously, it depends on the ability of the server to handle that many requests in parallel (potentially from multiple clients). You only wait 5 sec if the server can't parallel process or is overwhelmed. And, as sune said below, it also depends on caching. If those users can be cached, some of those requests may not even leave the client.

[Prasad Katti]

Thank you all. The IDS are not in sequence.

-Prasad