Need help naming endpoints for email and username availability

[Bryan Donovan]

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

Thanks!

Bryan

[Dolf Schimmel]

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.

Dolf

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.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
 
 

[PJD1328]

This is more of business or domain service than resource. So in this case i would do something like below

GET /services/checkAvailibility?username=XXXX
GET /services/checkAvailibility?email=XXXX
GET /services/checkAvailibility?username=XXXX&email=YYY

That way you can add more parameters if you need to and you can have few more capabilities in future.

I am open to feedback or suggestions.

[Mike Kelly]

HEAD /users?email=f...@bar.com

HEAD /users/dave

200 if taken, 204 if available

--

[Kristof Kotai]

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=a...@email.com

GET    /users/exists/?username=kevin

Which would only return 200 if it exists, 404 if it doesn't. No body.

Kristof

On Wednesday, November 14, 2012 8:05:57 AM UTC, Mike Kelly wrote:

HEAD /users?emai...@bar.com

HEAD /users/dave

200 if taken, 204 if available

On 13 Nov 2012, at 19:33, Bryan Donovan <brdo...@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?emai...@bar.com

[Bryan Donovan]

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.

--

[Dietrich Schulten]

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

[Bryan Donovan]

Thanks Dietrich, this might be something we will need to do. Good advice.