The clients of my company's API need endpoints that let them check if a username and/or email are available when a user signs up. E.g., after the user has entered a username, the client submits a request with that username and the server responds with some kind of status indicating if the username has already been taken or not.
I'm having trouble choosing RESTful paths and endpoint names for these. Any ideas?
Something like:
GET /something?username=foo GET /something?email=...@bar.com
I'm assuming you already have an end point for users, like /users and
/user/<nickname> ? If so, what I'm used to do in these cases is simply use
the url /user/nickname?noOp=true (no-op meaning 'no operation'). On an
application level I can keep the validation in sync, by definition. Also, I
personally consider this to be pretty restful, although I am interested in
what others would do.
On Tue, Nov 13, 2012 at 8:33 PM, Bryan Donovan <brdono...@gmail.com> wrote:
> The clients of my company's API need endpoints that let them check if a
> username and/or email are available when a user signs up. E.g., after the
> user has entered a username, the client submits a request with that
> username and the server responds with some kind of status indicating if the
> username has already been taken or not.
> I'm having trouble choosing RESTful paths and endpoint names for these.
> Any ideas?
> Something like:
> GET /something?username=foo
> GET /something?email=...@bar.com
> Thanks!
> Bryan
> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
On Tuesday, November 13, 2012 2:33:06 PM UTC-5, Bryan Donovan wrote:
> The clients of my company's API need endpoints that let them check if a > username and/or email are available when a user signs up. E.g., after the > user has entered a username, the client submits a request with that > username and the server responds with some kind of status indicating if the > username has already been taken or not.
> I'm having trouble choosing RESTful paths and endpoint names for these. > Any ideas?
> Something like:
> GET /something?username=foo > GET /something?email=f...@bar.com <javascript:>
> The clients of my company's API need endpoints that let them check if a username and/or email are available when a user signs up. E.g., after the user has entered a username, the client submits a request with that username and the server responds with some kind of status indicating if the username has already been taken or not.
> I'm having trouble choosing RESTful paths and endpoint names for these. Any ideas?
> Something like:
> GET /something?username=foo
> GET /something?email=...@bar.com
> Thanks!
> Bryan
> -- > You received this message because you are subscribed to the Google Groups "API Craft" group.
> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
I would do something similar to what Mike wrote. So
GET /users
would return a list of users. Normally, you would add the number of results in the header as well. How do you search amongst them? Like this:
GET /users/?field=value&field2=value...
So if the number of results is in the header, then using this:
HEAD /users/?field=value&field2=value...
where the number of results in the header is 0 / not 0 should solve the problem. I would only recommend this:
HEAD /users/dave
If the "dave" identifier would be the primary key in the DB. The HEAD solution is I think the strictly RESTful way of doing it. Others, like Foursquare use "actions" on resources, that's a bit mroe straightforward. Like https://developer.foursquare.com/docs/users/search So you would have something like this then:
GET /users/exists/?email=...@email.com GET /users/exists/?username=kevin
Which would only return 200 if it exists, 404 if it doesn't. No body.
On Wednesday, November 14, 2012 8:05:57 AM UTC, Mike Kelly wrote:
> HEAD /users?emai...@bar.com <javascript:> > HEAD /users/dave
> 200 if taken, 204 if available
> On 13 Nov 2012, at 19:33, Bryan Donovan <brdo...@gmail.com <javascript:>> > wrote:
> The clients of my company's API need endpoints that let them check if a > username and/or email are available when a user signs up. E.g., after the > user has entered a username, the client submits a request with that > username and the server responds with some kind of status indicating if the > username has already been taken or not.
> I'm having trouble choosing RESTful paths and endpoint names for these. > Any ideas?
> Something like:
> GET /something?username=foo > GET /something?emai...@bar.com <javascript:>
> Thanks! > Bryan
> -- > You received this message because you are subscribed to the Google Groups > "API Craft" group. > To unsubscribe from this group, send email to > api-craft+...@googlegroups.com <javascript:>. > Visit this group at http://groups.google.com/group/api-craft?hl=en.
> The clients of my company's API need endpoints that let them check if a username and/or email are available when a user signs up. E.g., after the user has entered a username, the client submits a request with that username and the server responds with some kind of status indicating if the username has already been taken or not.
> I'm having trouble choosing RESTful paths and endpoint names for these. Any ideas?
> Something like:
> GET /something?username=foo
> GET /something?email=...@bar.com
> Thanks!
> Bryan
> -- > You received this message because you are subscribed to the Google Groups "API Craft" group.
> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
Keep in mind that a response that says the nickname or email is available
might no longer be true by the time the write request comes in. Someone
else can take the same name in the meantime. We had to design a temporary
reservation which guaranteed that the write request succeeds. It also
returned suggestions and reserved them if the original request to reserve
failed. They used Spring remote, but for rest I would PUT the userid with
the username to a /username/reservation resource and return 201 created for
success, 200 for a repeated PUT of the same username, and 409 conflict with
suggestions in the body if the username is already taken or reserved by
someone else. Once the POST comes in, the server checks if it has an
appropriate reservation for the userid, otherwise it rejects the POST with
403 forbidden and says in the response that no reservation was found and
how to get one.
Best regards
Dietrich
Am 15.11.2012 21:59 schrieb "Bryan Donovan" <brdono...@gmail.com>:
> Thanks for all the suggestions! I'll have to think about this a bit, but
> I'm leaning toward something like GET /users?username=foo, or using HEAD.
> Sent from an iPhone.
> On Nov 13, 2012, at 11:33 AM, Bryan Donovan <brdono...@gmail.com> wrote:
> The clients of my company's API need endpoints that let them check if a
> username and/or email are available when a user signs up. E.g., after the
> user has entered a username, the client submits a request with that
> username and the server responds with some kind of status indicating if the
> username has already been taken or not.
> I'm having trouble choosing RESTful paths and endpoint names for these.
> Any ideas?
> Something like:
> GET /something?username=foo
> GET /something?email=...@bar.com
> Thanks!
> Bryan
> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> Keep in mind that a response that says the nickname or email is available might no longer be true by the time the write request comes in. Someone else can take the same name in the meantime. We had to design a temporary reservation which guaranteed that the write request succeeds. It also returned suggestions and reserved them if the original request to reserve failed. They used Spring remote, but for rest I would PUT the userid with the username to a /username/reservation resource and return 201 created for success, 200 for a repeated PUT of the same username, and 409 conflict with suggestions in the body if the username is already taken or reserved by someone else. Once the POST comes in, the server checks if it has an appropriate reservation for the userid, otherwise it rejects the POST with 403 forbidden and says in the response that no reservation was found and how to get one.
> Best regards
> Dietrich
> Am 15.11.2012 21:59 schrieb "Bryan Donovan" <brdono...@gmail.com>:
> Thanks for all the suggestions! I'll have to think about this a bit, but I'm leaning toward something like GET /users?username=foo, or using HEAD.
> Sent from an iPhone.
> On Nov 13, 2012, at 11:33 AM, Bryan Donovan <brdono...@gmail.com> wrote:
>> The clients of my company's API need endpoints that let them check if a username and/or email are available when a user signs up. E.g., after the user has entered a username, the client submits a request with that username and the server responds with some kind of status indicating if the username has already been taken or not.
>> I'm having trouble choosing RESTful paths and endpoint names for these. Any ideas?
>> Something like:
>> GET /something?username=foo
>> GET /something?email=...@bar.com
>> Thanks!
>> Bryan
>> -- >> You received this message because you are subscribed to the Google Groups "API Craft" group.
>> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "API Craft" group.
> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "API Craft" group.
> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
