[Pharo-users] Multiple NeoJSON mappings for the same domain object

Esteban Maringolo emaringolo at gmail.com
Wed Feb 13 07:53:22 EST 2019


Not in a hurry at all, I'm defining this part, so I can explore
different alternatives.

I'll explore the OpenAPI approach with JSONSchema as well.


Regards,

ps: What I liked about Stargate is that it manages other aspects of an
API such as CORS, HATEOAS [1] and resource versioning, but
JSON-HyperSchema [2] seems to provide a similar approach to HATEOAS, I
don't know if there something in OpenAPI to have multiple
representation versions of the same resource (so you preserve the
route, but make the API back AND forward compatible).

[1] https://en.wikipedia.org/wiki/HATEOAS
[2] https://www.ietf.org/archive/id/draft-handrews-json-schema-hyperschema-01.txt

Esteban A. Maringolo

El mié., 13 feb. 2019 a las 4:45, Norbert Hartl (<norbert at hartl.name>) escribió:
>
> If you are not in a hurry you can use JSON schema. That is also an external mapper which can validate. And the spec is serializable. You might miss some functionality but I could try to add that if you don‘t do. I would be happy to have more users of the library.
>
> If you use it for REST you could also use OpenAPI which I did. It uses the JSON schema stuff for doing it.
>
> Norbert
>
> > Am 13.02.2019 um 02:58 schrieb Esteban Maringolo <emaringolo at gmail.com>:
> >
> > Meanwhile I found another approach to solve this in the context of a
> > JSON/REST API.
> >
> > E.g. see #addRuleToEncode:to:using: in.
> > https://github.com/ba-st/Stargate/blob/release-candidate/source/Stargate-Examples/PetsRESTfulControllerSpecification.class.st
> >
> > Has a separate mapper for encoding and decoding, depending on the endpoint:
> >
> > Regards,
> >
> > Esteban A. Maringolo
> >
> > El mar., 12 feb. 2019 a las 19:34, Esteban Maringolo
> > (<emaringolo at gmail.com>) escribió:
> >>
> >> Hi all, Sven, :)
> >>
> >> I'm working on a domain model that will have different JSON
> >> representations for the same domain objects, so depending on the
> >> context it will return one representation or another.
> >>
> >> In the past to solve the multiple representations, what I did was to
> >> build "helper" methods that added the mappings to the mapper.
> >>
> >> So the process was like:
> >> 1. instantiate the mapper
> >> 2. call a #neoJsonSimple: mapper
> >> 3. configure the mapper by calling other mapping defining methods
> >> 4. convert the object to a JSON string.
> >>
> >> If I wanted an "extended" representation, in the step 2 I would call
> >> #neoJsonExtended: instead.
> >>
> >> But I find this "too manual" to scale.
> >>
> >> So... is there a better, ¿canonical?, way to achieve this?
> >>
> >>
> >> Thanks!
> >>
> >>
> >> ps: By now it will be only object -> JSON (so NeoJSONWriter), but in
> >> the future I might need to instantiate objects back from JSON, so the
> >> mappings should be for both mappers.
> >>
> >> Esteban A. Maringolo
> >
>
>



More information about the Pharo-users mailing list