Smalltalk › Pharo › Pharo Smalltalk Users

Best Practices for Adapting JSON based APIs

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

darth-cheney

Best Practices for Adapting JSON based APIs

Hello all,

Several times in the past couple of years I've found myself attempting to create objects that incorporate/adapt a given APIs specification -- in other words, building a mini, pharo based SDK for the given API. These are always JSON based APIs.

I am not sure what the best practices are for doing this and am looking for some wisdom from this list. I have a few questions:

1. When passing around JSON-based objects for a given API, is it better to work with Dictionaries or to create (for example) specific objects for specific kinds of JSON objects in the API -- ie for Stripe, would you just work with objects that read and parse Dictionaries or implement Transaction, User, CreditCard objects, etc, etc?

2. If you create objects for each kind of entity rather than using dictionaries, what do you do in the (rather common) case where the API specification allows for a lot of malleability in a given JSON object that gets passed in for a given kind of request? Often times there can be arbitrary, non-required key-value pairs set by the user for a given transaction/request/whatever on the JSON object. I'm not sure how this would translate to Pharo objects, especially if we are creating a method-per-key

3. Do you create a method per what would be a key in the spec's JSON object?

4. If a given API spec is itself written in JSON, do we have some way of "automatically" creating the equivalent objects in Pharo (since both are machine readable)?

I am currently considering developing a bare-bones proof of concept package for making a Matrix Client but I'm a bit flummoxed about how to proceed, since there seem to be many ways to do this -- some that might be worse than others for testing, abstraction, etc, etc.

Any advice is much appreciated. Thanks!

-- ,

Eric

Paul DeBruicker

Re: Best Practices for Adapting JSON based APIs

Hi -

1. There is a Stripe package here:
http://smalltalkhub.com/#!/~pdebruic/Stripe

MCHttpRepository
location: 'http://smalltalkhub.com/mc/pdebruic/Stripe/main'
user: ''
password: ''

You can see how it adapts to Stripe's changing API spec.

2. NeoJSONObject, which is part of Svens' NeoJSON package & JsonObject of
the JSON package here:

http://smalltalkhub.com/#!/~PharoExtras/JSON

each overrides #doesNotUnderstand: to return nil when you send messages the
JSON object doesn't define. E.g. given JSON of

{a: 1, b: 2}

you can

myJson:=Json readFrom: '{"a": 1, "b":2}' readStream

myJson a. "1"
myJson b: 25. "sets b to 25"
myJson b. "25"
myJson zebra. "nil"

I like and use both the JSON packages but don't like using the overriden
#dnu mechanism because you cannot track implementors. So later when you
want to know what #zebra does you cannot see it and have to remember its a
JSON object and you're doing a dictionary lookup. But its a flexible way to
deal with JSON objects sith varying fields.

3. Yes. Because I want to be able to see implementors.

4. No, not from an arbitrary spec. Google publishes some of their APIs as
JSON specs and there is a project to interpret those specs and automatically
build objects and interfaces here

https://github.com/seandenigris/St-Google-API

If there is a standard way to define APIs (swagger maybe? I'm not sure) then
you could make something that does what you want for that API spec spec.

Hope this helps

darth-cheney wrote

> Hello all,
>
> Several times in the past couple of years I've found myself attempting to
> create objects that incorporate/adapt a given APIs specification -- in
> other words, building a mini, pharo based SDK for the given API. These are
> always JSON based APIs.
>
> I am not sure what the best practices are for doing this and am looking
> for
> some wisdom from this list. I have a few questions:
>
> 1. When passing around JSON-based objects for a given API, is it better to
> work with Dictionaries or to create (for example) specific objects for
> specific kinds of JSON objects in the API -- ie for Stripe, would you just
> work with objects that read and parse Dictionaries or implement
> Transaction, User, CreditCard objects, etc, etc?
>
> 2. If you create objects for each kind of entity rather than using
> dictionaries, what do you do in the (rather common) case where the API
> specification allows for a lot of malleability in a given JSON object that
> gets passed in for a given kind of request? Often times there can be
> arbitrary, non-required key-value pairs set by the user for a given
> transaction/request/whatever on the JSON object. I'm not sure how this
> would translate to Pharo objects, especially if we are creating a
> method-per-key
> 3. Do you create a method per what would be a key in the spec's JSON
> object?
> 4. If a given API spec is itself written in JSON, do we have some way of
> "automatically" creating the equivalent objects in Pharo (since both are
> machine readable)?
>
> I am currently considering developing a bare-bones proof of concept
> package
> for making a Matrix Client <https://matrix.org/docs/spec> but I'm a
> bit
> flummoxed about how to proceed, since there seem to be many ways to do
> this
> -- some that might be worse than others for testing, abstraction, etc,
> etc.
>
> Any advice is much appreciated. Thanks!
>
> -- ,
> Eric

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html