1.) POST the list of users to create a "user list" (a noun). Return 201 "Created" with a "Location" header to a URL like /userlists/{$userlist_id}2.) GET /userlists/{$userlist_id} to retrieve the list of users.3.) Also support DELETE /userlists/{$userlist_id} to explicitly purge the list.4.) Optionally delete a user list after a length of time since last accessed (1 hour, 1 day, 30 days?), assuming no system would ever need to "bookmark" the list.
Andy Berryman
Technical Lead
919.228.4857 office
866.225.3085 fax
2701 Aerial Center Parkway
Morrisville | North Carolina | 27560
www.channeladvisor.com - Be Seen
The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.
I'm curious, why do you consider this solution horrible? You have
created a new resource /facebookfriends, which you are treating like a
data processing resource as is described in the HTTP spec. You are
passing a list of Ids to it and it is returning to you a list of
users.
From my perspective, I see nothing wrong with this. Is it just the
name of the resource that you don't like?
Darrel
I'm afraid I don't know what you mean by "a non-resourceful method".
However, there absolutely no requirement in the HTTP spec that says a
POST needs to create or store anything.
> I think it really belongs in the
> API Users controller (/users/1/friends?facebook_list=id1,id2,id3...)
> and that it should be called via a GET (as a POST request implies I am
> creating something, which I am not.... unless I go with Mike's
> suggestion).
>
A POST does not imply that you are creating something. A POST might
create something, or it might not. If you get back a 201 then it did
create something.
Here are some examples of the types of things you can do with POST
from the HTTP spec[1] :
o Annotation of existing resources;
o Posting a message to a bulletin board, newsgroup, mailing list, or
similar group of articles;
o Providing a block of data, such as the result of submitting a
form, to a data-handling process;
o Extending a database through an append operation.
If you look at the third option and paraphrasing, you are providing a
block of data to a data handling process. This is a completely valid
use of POST. The notion of /facebookfriends as a "data-handling"
resource is just as valid a resource as a UserList resource that you
can conceptually create and delete.
I frequently find people box themselves into a corner by mapping HTTP
methods to CRUD operations and then ask, how can I do non-CRUD stuff.
The answer is to stop mapping HTTP methods to CRUD.
Darrel
[1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#page-20