2

I have an API which include a registration and login process. Both process have an authentication sub-process. This sub-process are many steps which API validate a client specific data.

I have many doubts about names for authentication process. This is my approach:

Registration process (It creates an account)

POST /accounts/authentication (start authentication process, generate internal keys but doesn't return any token)
POST /accounts/authentication/data1/validation (validate data1 of client)

Login process (When client want to access his created account)

POST /sessions/authentication (start authentication process, generate internal keys but doesn't return any token)
POST /sessions/authentication/data1/validation ( validate data1)
POST /sessions/authentication/data2/validation ( validate data2)

Additionally, I have a service which return the data (data1 or data2) that I should validate in a next step.

GET /attributes

( I can't specific the real name but My approach it should be a plural noun)

Well, I would like if my approach is correct.

Thanks!

EDIT 1

Firstly, I have a token which is generated previously. I sent this token in headers. Then, the first service (.../authentication) generate internal tokens. The next services validate these tokens internally. Due to security reasons I can't use these tokens in URL's.I have a Redis DB which support all process.

Regarding to the another service (.../data1/validation). "Data1" is an specific data attribute of the client. According to business rules and application flow, I need an specific service for validating this specific data attribute.

I hope my additional explanation could help you to understand my problem.

Thanks :)

Improve this question
2

As a practice, you try to associate a url with a resource rather than behaviour. with that in mind
POST /accounts/authentication: I don't understand what start authentication process does, but if you are generating a token, let's just say GET /token. When you are using POST, generally your data does not go in the URL as mentioned in POST /accounts/authentication/data1/validation This should be a really good guide: resource-naming

Improve this answer
  • I've update my question. I would like if I could use a HTTP GET for the first service although this does not return body and if my proposal (POST .../data1/validation for the second service is correct – Cesar Miguel Dec 27 '19 at 17:00
  • Yes, you can use GET for the first service. Since data1 is an attribute and not a resource itself, this should ideally go as a parameter in your POST. Regarding the API itself, as mentioned in the answer, /data1/validation also refers to a certain operation rather than resource. As a general practice, let the API refer to a resource and use return types effectively. Example: if you want to verify if a token is valid, you could do POST /token. Let the API do the validation and return a 400/403 if invalid, or 200/201if all OK. – skott Dec 29 '19 at 5:04
1

From the question it is not exactly clear how server-side remains stateless. There is one pattern, which may be useful for representing a process.

The idea is to create a temporary resource (eg registration or login) in a relevant store, and then work by addressing them.

For example:

POST /accounts/authentication
# this will give you Location: /accounts/authentication/01234-6547
POST /accounts/authentication/01234-6547/data1/validate
...

You can even get the status, which will possibly return links to more steps, if needed (in a more HATEOAS fashion):

GET /accounts/authentication/01234-6547

I do not remember where I got that idea originally, but this article seems to describe the approach.

All that said, unless you are working on OAuth3 or something very new, it's probably better to stick with how it is usually done in some mature systems even if it is not quite REST. This relates to how secure the solution will be and small details may matter.

Improve this answer
  • I've updated my question. As I said, I can't use token values in service URL – Cesar Miguel Dec 27 '19 at 2:50
  • The 01234-6547 in the URL is not a token. The token still needs to be included in the headers or in the payload. – Roman Susi Dec 27 '19 at 5:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.