Feature | Naive signup capabilities implementation

[EstebanBorai]

A naive version of the signup service is implemented, providing the capability of registering users in the platform.

Its important to note that theres a lot of work to be done in this feature, including:

• e2e testing
• Validations on incoming payload
• Code cleaning
• Error handling
• Configure SQLx for offline mode to make workflows run

And perhaps theres more points I will encounter for the moment I work on those missing items.

I think is important to merge this version as this establishes a project scaffold for all of us to contribute/expand this project.

Example

In order to register a new user you must send an HTTP request which looks like the following:

POST /signup HTTP/1.1
Content-Type: application/json; charset=utf-8
Host: 0.0.0.0:7878
Connection: close
Content-Length: 101

{"email":"eborai@hilow.com","username":"eborai","name":"Esteban","surname":"Borai","password":"1234"}

Note: This PR depends on #18 and #22

[EstebanBorai]

@morenol if this PR results as a stopper for other PRs authored by you, feel free to go ahead with #18 and #22 and I will rebase against main when those PRs are landed.

At the moment Im not able to fix those but will do later today!

[rafacouto]

I suggest to move the URI under /users (/users/signup or /users/register) since operations are more related to user than session.

[EstebanBorai]

I suggest to move the URI under /users (/users/signup or /users/register) since operations are more related to user than session.

Thing is that neither login or signup consume a User resource. Neither of these endpoints relates to a User. When interacting with authentication you provide credentials such as email or username and password and you don't expect the User resource to be in the response from the server but a Token which is then used to gather User relevant details required by the client.

If you check the documentation: https://github.com/rust-lang-ve/hilow#user-management, you will notice that theres an endpoint for the User resource which retrieves the user for the client, this requires the token you gather when consuming either this or the login endpoint.

[rafacouto]

I suggest to move the URI under /users (/users/signup or /users/register) since operations are more related to user than session.

Thing is that neither login or signup consume a User resource. Neither of these endpoints relates to a User. When interacting with authentication you provide credentials such as email or username and password and you don't expect the User resource to be in the response from the server but a Token which is then used to gather User relevant details required by the client.

If you check the documentation: https://github.com/rust-lang-ve/hilow#user-management, you will notice that theres an endpoint for the User resource which retrieves the user for the client, this requires the token you gather when consuming either this or the login endpoint.

login and logout are clearly related to session (not user) so I'd move them to /session path. However register is a method for registering users. You are mixing URI path and authentication concepts and they are not linked in modern APIs. The goal here should be to understand method domains. Anyway, I accept the PR!

[EstebanBorai]

I suggest to move the URI under /users (/users/signup or /users/register) since operations are more related to user than session.

Thing is that neither login or signup consume a User resource. Neither of these endpoints relates to a User. When interacting with authentication you provide credentials such as email or username and password and you don't expect the User resource to be in the response from the server but a Token which is then used to gather User relevant details required by the client.

If you check the documentation: https://github.com/rust-lang-ve/hilow#user-management, you will notice that theres an endpoint for the User resource which retrieves the user for the client, this requires the token you gather when consuming either this or the login endpoint.

login and logout are clearly related to session (not user) so I'd move them to /session path. However register is a method for registering users. You are mixing URI path and authentication concepts and they are not linked in modern APIs. The goal here should be to understand method domains. Anyway, I accept the PR!

The definition of routes was implemented iterations before.

We could address this in a Discussion perhaps?

This PR implements features beyond routing and in case routes have to be updated we could land another PR in the future introducing such change.