Implement coercion between HTTP and LB4 layers(converter and deserialize)

[shimks]

Description / Steps to reproduce / Feature proposal

This issue is a follow up to #1057.
For DP3, we'd like to provide coercion between the http-LB4 layer.

See also #750 and #100.

Acceptance Criteria

• Create an extensive OpenAPI type -> JS run-time type converters

  • Create string type to Date type converter (done by Use OpenAPI v3 spec to coerce primitives in query, path and headers #750)
  • Create string type to Buffer type converter (done by Use OpenAPI v3 spec to coerce primitives in query, path and headers #750)
  • Create other string type to JS run-time converter (like number and boolean; done by Use OpenAPI v3 spec to coerce primitives in query, path and headers #750)
  • ObjectID
  • GeoPoint
  • Any LoopBack model (e.g. Address)

• Make it easy for @requestBody (and other parameter-level decorators) to specify custom model class that should be used to validate the request body when the actual parameter is of type DeepPartial<MyModel>. Make sure this works for Array<DeepPartial<MyModel>> too. This is tracked by OpenAPI decorator does not properly generate schemas of type Partial #1179.

• A registry of deserializers related to type information. Modify decorators to allow users to provide a reference to a custom deserializer to use. This is related to Extensibility epic, see Spike: allow extensions to contribute custom validators and serializers/deserializers for REST layer #1463 which is tracking this feature.

  // what the signature of a 'deserializer' looks like
  deserializer(rawvalue: any, paramMeta: parameterMetadata)

See Reporting Issues for more tips on writing good issues

[dhmlau]

@shimks , good for estimation? if so, pls move to needs estimate column. thanks.

[shimks]

Rejecting as we've decided on splitting the story into two: coercion through openapi spec, and validation + focus on extension capabilities of both coercion and validaion

[bajtos]

@shimks

Rejecting as we've decided on splitting the story into two: coercion through openapi spec, and validation + focus on extension capabilities of both coercion and validaion

Should we close this issue then?

[bajtos]

What is the relation of this story to #750 and #100?

[shimks]

@bajtos Oops, that message was for rejecting for 'estimation' when it was initially brought up. I've updated the criteria and intended this to be the main task to work on, but essentially #750 and this issue seem to be a duplicate. Which one should we close?

[jannyHou]

@shimks I think #750 is created to implement the first criteria in this story:

Create an extensive OpenAPI type -> JS run-time type converters
Create string type to Date type converter
Create string type to Buffer type converter
Create other string type to JS run-time converter (like number and boolean)

I would suggest we still use #750 for implementing the first criteria, and get back to this issue when work on the second criteria

Create a metadata 'type' for parameters, which may include inference from explicitly specified metadata

[jannyHou]

How about use #100 as the deserialization story?(which is currently the second acceptance criteria in this story)

[bajtos]

How about use #100 as the deserialization story?(which is currently the second acceptance criteria in this story)

IMO, #100 is covering a slightly different aspect of coercion, see the examples I added to issue description few moments ago. I am cross-posting them below.

1. Encode an array of strings as a comma-separated list.

   GET /api/domains?tlds=com,net,eu
   

   Sets tlds argument to ['com', 'net', 'eu'].

2. Send a "filter" query as JSON-encoded value.

   GET /api/products?filter={"where":{"name":"Pen"},"limit":10}
   

   Sets filter argument to {where: {name: 'Pen'}, limit: 10}.

[bajtos]

Discussed the scope & acceptance criteria with @raymondfeng and @jannyHou . Removed from GA, we should split this story into multiple smaller ones.

[stale]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[stale]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.