-MikeI've been planning to post to the list and ask if client SDK design is appropriate for this list, so you beat me to it! Thanks Daniel for bringing it up.Specifically I'm interested in designing a PHP base class that could subclassed to handle most any web API (yes I know if all web APIs were all hypermedia we'd only need one client SDK per language, and that assuming we had a standard for hypermedia. But I digress...)What I've found after coding many different client SDKs for web APIs is that each API class I build is similar but turns out slightly different mostly because of authorization but some because of content type consumed. However I keep feeling like there's an emergent pattern just begging to be exposed. If we could identify it we could create an PHP level interface that could be used to implement client SDKs consistently across many different APIs. I also think doing so would help reveal many of the requirements needed to make it easier for a client developer to consume a hypermedia API.And though I need PHP (and Javascript) the same concept should apply to Ruby, Python, Perl, Java, .NET etc. where each could see a similar pattern but applied to their language/platform.So, has anyone of the list done any research in this area and/or have any insight? (Or is this list not the right place to discuss client SDK design?)
--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group, send email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group, send email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
Thanks for asking! ... Right now I cannot remember the argument I made for it when I started - duh. I better think this through again and get back with explanation (if possible).
/Jørn
our Backbone extension is quite simple. For example, we have a self node in the json response that we parse for every model instantiated. In hindsight, I would have preferred not to have used the formal class inheritance model and opted for something similar to Backbone Layout manager for augmenting the model class, but that can be factored in later. Everything is wrapped in an AMD module for us, but i've stripped that out from below:
var Self = Backbone.Dcapi.Self = function(params) {
_.extend(this, _.pick(params, "type", "uri", "href", "max-age"));
if (this.uri) {
this.id = Backbone.Dcapi.parseId(this.uri);
}
};
// Attach all inheritable methods to the Self prototype.
_.extend(Self.prototype, {
// ...
});
Backbone.Dcapi.Model = Backbone.Model.extend({
// ...
zoom: null,
url: function() {
var uriSelf, baseUrl;
if (this.get("self") && this.get("self").href) {
baseUrl = this.get("self").href;
} else {
baseUrl = Backbone.Model.prototype.url.call(this);
}
if (this.zoom) {
uriSelf = URI(baseUrl);
uriSelf.removeSearch("zoom").addSearch("zoom", this.zoom);
return uriSelf.toString();
}
return baseUrl;
}
// ...
});
Actual model classes are therefore pretty straight forward:
Cart.Models.ItemPrice = Backbone.Dcapi.Model.extend({
afterParse: function (response, model) {
model['list-price'] = _.first(jsonPath(response, "$..['list-price'][0]"));
model['purchase-price'] = _.first(jsonPath(response, "$..['purchase-price'][0]"));
return model;
}
});