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
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:
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.
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.
Path variable in the URL must begin with colon and then alpha-numeric with underscore string, i.e : then a-zA-Z0-9_
It must be possible to define service method not only with static qualifier, like today, but also using path-variables:
Idea is to support RESTful scalecube services where clients use path variables as a part of their service contract.
Quick reminder of Path Variables:
When making an actual request, the client will replace
{userId}
with a specific user ID, like this:GET /users/{userId}
userId
GET /users/123
PUT /users/{userId}
userId
PUT /users/123
DELETE /users/{userId}
userId
DELETE /users/123
GET /users/{userId}/posts/{postId}
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:
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.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.Path variable in the URL must begin with colon and then alpha-numeric with underscore string, i.e
:
thena-zA-Z0-9_