[Pharo-users] Best Practices for Adapting JSON based APIs

[Paul DeBruicker]

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