You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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_
The text was updated successfully, but these errors were encountered:
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:Example Usage in REST API Design:
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_
The text was updated successfully, but these errors were encountered: