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