Open cyb3r4nt opened 2 years ago
What is the best way to add validations for the API input parameters ? Also how to handle the case when the API input parameter is an interface, and several different implementation class are valid input parameters for the API ?
What is the best way to add validations for the API input parameters ?
In my opinion, this framework should not deal with validation of users' business objects. It may only provide provide deserialization for required types, but validation should be done somewhere else in the users' code. Also, in my opinion, deserialization and validation should be two different steps: successful receival of the object and validation with proper logging inside the application.
The best option is to manually check the object just after framework has returned control into users' code.
The second option is to use request interceptors, like this one: https://github.com/briandilley/jsonrpc4j/blob/master/src/main/java/com/googlecode/jsonrpc4j/RequestInterceptor.java
There is also possibility to use javax.validation
, but this is not quite supported yet.
There is also one open PR which tries to do this, https://github.com/briandilley/jsonrpc4j/pull/285.
It is also not quite clear who and where needs to call the javax.validation
: jsonrpc4j
or Spring framework
or users' code.
Current issue is not quite related to the object validation, an it descibes a bug about the JSON-RPC id
field and error handling.
Also how to handle the case when the API input parameter is an interface, and several different implementation class are valid input parameters for the API ?
How the framework will know which concrete implementation to inject into users' method? Is there any good possibility how to express this using JSON objects? What are you trying to achieve when interface is declared in the method parameters?
When remote methods are called via RPC, then data is exchanged between remote processes. And framework gives the ability to map that data into some objects. This data is only some messages between two processes. It is better if remote logic does not know anything about your interfaces and various implementations. API contract usually requires some well known parameters, like primitive types and collections, and their composition.
If you really need this, then there are some interceptors provided by this framework, which may transform objects. Or even better approach to receive the message, as data object, and transform it to required interface and implementation directly in the users' code.
During upgrade to newer
1.6.0
version an error related to invalid handling of JSON-RPC id was discovered.Suppose you have a server with following interface:
When a valid json, but with invalid parameters, is sent to server:
Then server responds with
, where initial
id
value is lost.This is also true for the batch requests, where multiple requests are sent at once. It should be possible to find a failed request by
id
from the response.The "JSON parse error"
-32700
is not really correct here because:Valid error probably should be the "Invalid params"
-32602
, because wrong parameter was sent.More detailed log (code line numbers may be wrong):
Variant with batching:
The behavior was correct in previous
1.5.3
version, but in1.6.0
server started to outputnull
values forid
in responses. This is caused by the recent change in the error handling logic: https://github.com/briandilley/jsonrpc4j/blob/1.6.0/src/main/java/com/googlecode/jsonrpc4j/JsonRpcBasicServer.java#L466