Server handlers

[alelb]

In order to complete server handlers, here a list of TODO:

• [x] API for update (PUT) resources Notice that PUT MUST NOT be used to create new resources

• [x] Search, Put and Delete handlers

• [ ] field validation when posting a resource. @leodido note that we can decorate field of the struct CommonAttribute with `binding:"required" etc, but we cannot do the same with the datatype.Complex resource data.

• [x] add in create and update api the business logic to retrieve the resource just created/updated

to be continued

[leodido]

Regarding the search there should be query.Resources().

[leodido]

@alelb yes, I know it from some days and as I saw 3 days ago I do not like this ...

Please investigate whether there is the possibility to apply bindings at runtime on a map ... I do not thnk it is supported by gin framework, but hey let's try!

[leogr]

@leodido Apply bindings at runtime is a wrong way, even it was supported by gin. Those fields depends on the schema that's not static, like tags in structs. Furthermore, validation cannot be performed in a centralised way, due the different nature of rule checks required by the RFC

Marshalling functions should already throw an error when type mismatches (yeah, it's kind of validation, errors should be handled and reported to the clients as RFC mandates).

Then, write APIs have to check for required fields and enforce mutability rules. Note that validation rules may be different across POST, PUT, and PATH ops (eg. "immutable" means write-once field, so it's allowed by POST but cannot be changed anymore with PUT) Also, some tasks to perform on incoming data are not validation steps, but filtering (ie. for "readOnly" fields)

Uniqueness validation on fields can be performed within the storage layer, by catching the db's error on unique-indexes. We have to handle this, we cannot use a simple validator.

Check this too, even my be I was wrong about "required".