3

I have a route on my server /registered_contacts, 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)

ambertch
  • 7,581
  • 4
  • 28
  • 40
  • BTW, one thing you might think about is why you're designing things this way. You might not have a choice, but what you're describing above is akin to supporting a Web-ified "IN" WHERE clause, which isn't usually a good idea and usually doesn't scale for large values. If there's a nice way to refer to that collection with a single label/term, it might be worthwhile (this is essentially what the POST-a-filter approach also offered below suggests). – kvista Jan 12 '11 at 00:51
  • yeah, you've hit the nail on my dilemma. I'll probably continue as is right now (a few hundred values at most currently) and then later on if/when needed, adopt Will's suggestion to post to a filter resource – ambertch Jan 12 '11 at 01:04

2 Answers2

4

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.

Will Hartung
  • 115,893
  • 19
  • 128
  • 203
2

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.

kvista
  • 5,039
  • 1
  • 23
  • 25