scalecube / scalecube-services

Microservices library - scalecube-services is a high throughput, low latency reactive microservices library built to scale. It features: API-Gateways, service-discovery, service-load-balancing, the architecture supports plug-and-play service communication modules and features. built to provide performance and low-latency real-time stream-processing
http://scalecube.github.io/
Apache License 2.0
611 stars 105 forks source link

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

Open artem-v opened 2 weeks ago

artem-v commented 2 weeks ago

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 commented 1 week ago

chanage

two dots

to

colon

artem-v commented 1 week ago

@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