Question on REST conventions: retrieving information where lots of params are needed

I have a route on my server /registered_c开发者_开发知识库ontacts, which takes as params a long array of ids, lookups up which of those ids are registered in the database, and returns that subset.

Which HTTP method should this be?

It's currently a GET request since I figured it's GET'ing something, but then I'm also a bit uneasy with the long array of ids, which ends up making a request to an endpoint like:

www.server.com/registered_contacts?ids[2]=bob&ids[54]=jon&ids[23]=jack...etc. etc.

One could argue that I'm not actually getting a remote "thing" like /registered/contacts/42, one could also argue that it is a resource which I am neither updating, deleting, or creating... so that leaves getting?

(One worry I also have there is the header getting larger than a packet size, not sure if that becomes an issue)

---

Assuming you don't run in to some GET command length limit, which do exist, you're fine.

Another mechanism is to take your criteria, POST it to a "filter" resource, and then take the resulting URI from that, and then use that URI as the argument for the GET.

Create the filter:
POST /filter

ids[2]=bob......

Result:
HTTP/1.1 301 Moved Permanently
Location: /filter/1234

Use the filter:
GET /registerd_contacts?filter=http://example.com/filter/1234

Your filters are a first class resource that you can CRUD if you like, or they can "go away" in a day, or whatever you want.

---

No, GET is the right method. You're essentially generating a search result based on a long list of criteria. Your method is (semantically speaking) idempotent, which why it's not a good fit for a POST.