Raz Buchnik
Raz Buchnik

Reputation: 8401

REST API what is the proper way of URI naming using nouns and not verbs?

I have a login and I need to do something like this:

1. POST .../authentication/login

2. POST .../authentication/verifyToken

3. POST .../authentication/forgotPassword
  1. Will ask for a phone and a password.
  2. Will ask for an auth token.
  3. Will ask for a phone and a password.

But as I read, this structure is not good since it contains verbs rather than nouns.

I have tried to make something like this:

1. POST .../sessions/new
2. GET .../sessions/:token
3. GET .../sessions/forgot

1. Will create a new token, based on phone and password correct credentials.
2. Will verify the token validation or expiration.
3. Will send a SMS within a new password or a new temporary password reset code.

This first method is not REST. But its totally clear. You can read the URL and understand exactly what it gonna to do. You do not need any kind of explanation.

However, more and more articles say that verbs in REST is not RESTFUL and thus, not a good practice to achieve.

What is the proper way of handle this?

Upvotes: 0

Views: 1683

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57249

REST doesn't care what spelling you use for your resource identifiers.

But as I read, this structure is not good since it contains verbs rather than nouns.

The structure is fine.

You can read the URL and understand exactly what it gonna to do.

Right -- REST does not care if you can read the URL and understand what it is going to do.

URL/URI are identifiers, in the same way that variable names in your program are identifiers. Your compiler doesn't particularly care whether your variable is named accountBalance, purpleMonkeyDishwasher, or x. The spellings described in our coding standards are for human readers, and the same is true for hackable urls.

However, more and more articles say that verbs in REST is not RESTFUL and thus, not a good practice to achieve.

REST is an architectural style

As an architectural style for network-based applications, its definition is presented in the dissertation incrementally, as an accumulation of design constraints that derive from nine pre-existing architectural styles and five additional constraints unique to the Web

Fielding describes the constraints in his thesis; any who claim that verbs in identifiers "are not RESTful" should be able to point to a specific constraint that they violate.

I have yet to see a compelling argument that any of the REST constraints are violated by identifier spellings.

Upvotes: 2

sschrass
sschrass

Reputation: 7166

First I would not use the term session. This implies a server side state, what is problematic in stateless communication as REST requires.

So your problem could be solved by modeling resources, probably like:

GET ./authentication/token

to get a token if valid credentials provided in the request headers.

GET ./authentication/password

to get a new temporary password if E-mail address provided in the request headers.

You also can use POST in order to transport values in the request body.

Be aware of that the service should answer with an HTTP 204 in case of the result is being sent by SMS.

Upvotes: 1

Related Questions