Multiple NeoJSON mappings for the same domain object
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
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-Exa... 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@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
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@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-Exa...
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@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
Forgot to add the links https://github.com/zweidenker/JSONSchema https://github.com/zweidenker/OpenAPI Norbert
Am 13.02.2019 um 08:44 schrieb Norbert Hartl <norbert@hartl.name>:
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@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-Exa...
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@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
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.tx... Esteban A. Maringolo El mié., 13 feb. 2019 a las 4:45, Norbert Hartl (<norbert@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@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-Exa...
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@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
Am 13.02.2019 um 13:53 schrieb Esteban Maringolo <emaringolo@gmail.com>:
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).
Is there any documentation about stargate? Caring about CORS is surely useful. But I never got why HATEOAS is useful. It adds a lot of complexity with little use. Norbert
[1] https://en.wikipedia.org/wiki/HATEOAS [2] https://www.ietf.org/archive/id/draft-handrews-json-schema-hyperschema-01.tx...
Esteban A. Maringolo
El mié., 13 feb. 2019 a las 4:45, Norbert Hartl (<norbert@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@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-Exa...
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@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
Hi, sadly there is no documentation about Stargate yet, we did the first release just 20 days ago. Regarding HATEOAS, is an optional feature and we're testing it usefulness right now. Stargate is built on top of Zinc and Teapot and it has the following features: - Content negotiation allows serving different representations of a resource. E.g. "application/json;version=1.0.0" and "application/json;version=1.0.1" serve different representations of a resource. We think this will allow us to grow in easily our APIs. - Optional resource pagination support. - Optional HATEOAS support. - ETag generation. PS: We already took note of https://github.com/zweidenker/JSONSchema and https://github.com/zweidenker/OpenAPI. Both projects look great. On Wed, Feb 13, 2019 at 12:58 PM Norbert Hartl <norbert@hartl.name> wrote:
Am 13.02.2019 um 13:53 schrieb Esteban Maringolo <emaringolo@gmail.com>:
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).
Is there any documentation about stargate? Caring about CORS is surely useful. But I never got why HATEOAS is useful. It adds a lot of complexity with little use.
Norbert
[1] https://en.wikipedia.org/wiki/HATEOAS [2] https://www.ietf.org/archive/id/draft-handrews-json-schema-hyperschema-01.tx...
Esteban A. Maringolo
El mié., 13 feb. 2019 a las 4:45, Norbert Hartl (<norbert@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@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-Exa...
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@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
Wow, first time I heard about https://github.com/ba-st/Stargate - seems like a great project. So much is happening in and around Pharo, it is really impossible to follow everything.
On 13 Feb 2019, at 02:58, Esteban Maringolo <emaringolo@gmail.com> wrote:
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-Exa...
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@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
Yes, there is a lot going on. We're still missing a "featured stack" (at least one) that integrates all the parts of a "common" application need. "Necessity is the mother of invention" :) Regards, Esteban A. Maringolo El mié., 13 feb. 2019 a las 5:33, Sven Van Caekenberghe (<sven@stfx.eu>) escribió:
Wow, first time I heard about https://github.com/ba-st/Stargate - seems like a great project.
So much is happening in and around Pharo, it is really impossible to follow everything.
On 13 Feb 2019, at 02:58, Esteban Maringolo <emaringolo@gmail.com> wrote:
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-Exa...
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@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
participants (4)
-
Esteban Maringolo -
Francisco Ortiz Peñaloza -
Norbert Hartl -
Sven Van Caekenberghe