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
