Add required parameter checks for client side serialization/deseriali… #283
Conversation
There was a problem hiding this comment.
I don't know if disabling IDs is the best solution for the client side.
For client side operations, perhaps we should just use the IdEncoderBase32 class which doesn't encrypt/decrypt the IDs but rather just converts them to/from base32 form. This would allow a client to parse IDs correctly and reuse them in subsequent requests.
One way to do it would be to fallback to IdEncoders32 in the base ResourceBinding
If argument idEncoders is null, just set it to a new IdEncoders32()
Then I think you can remove all the tests in the individual binding classes (need to keep checking for the case where the key is null though).
| @@ -109,7 +109,7 @@ public IObsData deserialize(JsonReader reader) throws IOException | |||
| obs.withPhenomenonTime(OffsetDateTime.parse(reader.nextString()).toInstant()); | |||
| else if ("resultTime".equals(propName)) | |||
| obs.withResultTime(OffsetDateTime.parse(reader.nextString()).toInstant()); | |||
| else if ("foi@id".equals(propName)) | |||
| else if ("foi@id".equals(propName) && !ctx.isClientSide()) | |||
There was a problem hiding this comment.
We need at least this ID on the client side too.
The client needs to be able to parse it and also assign an FOI to an observation when posting it to the server.
…zation
Checks if requests are client side for some parameters that are not required in response body / request body. This and a small change in the client module fix
ConSysApiClientandConSysApiClientModule