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.