> Am 13.02.2019 um 13:53 schrieb Esteban Maringolo <emaring...@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.txt
>
> Esteban A. Maringolo
>
>> El mié., 13 feb. 2019 a las 4:45, Norbert Hartl (<norb...@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 <emaring...@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
>>> (<emaring...@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
>>>
>>
>>
>
