Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support path-variables in qualifiers (dynamic qualifiers) #863

Open
Tracked by #862
artem-v opened this issue Oct 11, 2024 · 2 comments
Open
Tracked by #862

Support path-variables in qualifiers (dynamic qualifiers) #863

artem-v opened this issue Oct 11, 2024 · 2 comments
Assignees

Comments

@artem-v
Copy link
Contributor

artem-v commented Oct 11, 2024

It must be possible to define service method not only with static qualifier, like today, but also using path-variables:

@ServiceMethod("foo/:foo/bar/:bar/cuku/:cuku")

Idea is to support RESTful scalecube services where clients use path variables as a part of their service contract.

Quick reminder of Path Variables:

GET /users/{userId}

When making an actual request, the client will replace {userId} with a specific user ID, like this:

GET /users/123

Example Usage in REST API Design:

Description URL Action Example
Retrieving a resource GET /users/{userId} Fetch the user with the specific userId GET /users/123
Modifying a resource PUT /users/{userId} Update the user with the specific userId PUT /users/123
Deleting a resource DELETE /users/{userId} Delete the user with the specific userId DELETE /users/123
Nested resources GET /users/{userId}/posts/{postId} Fetch a specific post (postId) by a specific user (userId) GET /users/123/posts/456

In this task we will support only URLs that follow best practices, and URLs that don't follow best practices we will not support. This will help to ensure clients that their API design remains clean, scalable, and intuitive, while adhering to the principles of REST.

Validation rules:

  1. We cannot support unlimited depth in URL (GET /users/{userId}/posts/{postId}/comments/{commentId}/likes/{likeId}/...), hence let's take as limit 3 path variables, if client is defining more than that, then we should throw exception.

  2. Using a URL like GET /{userId}/{postId}/{commentId}/{likeId} is not considered good practice in RESTful API design, hence we will reject such definition, and throw exception.

  3. Path variable in the URL must begin with colon and then alpha-numeric with underscore string, i.e : then a-zA-Z0-9_

@aharonha
Copy link
Contributor

chanage

two dots

to

colon

@artem-v
Copy link
Contributor Author

artem-v commented Oct 14, 2024

@snripa this feature doesn't have dependencies on others, it's not even feature of http or webdocket. But let's keep it in scope RESTful epic

@artem-v artem-v assigned artem-v and unassigned snripa Oct 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants