Re: R: R: Social API: Scope

hello.

On 2014-08-01, 9:30 , Goix Laurent Walter wrote:
>>> Note that there will be some interactions. However, one can imagine a
>>> standardized social JS client API sharing social data from a single origin
>>> embedded via an iframe without any open standards for federation.
>> [Owen] Of course. We can consider three layers: Server-to-Server,
>> Client-to-Server, and a JavaScript rich content API (which might be
>> implemented by the "container" in terms of the Client-to-Server API.

i guess i am not quite sure what a "server-to-server" API actually is 
(in terms of differentiating it from a "client-to-server" API). can you 
please clarify? wouldn't any network API necessarily create a context in 
which one server is a client, and the other one is a server, if that 
former server happens to request something from the latter one? or is 
there specific functionality you have in mind that would not be 
available to "regular clients", something like "bulk sync" or whatever 
else would be a rather specific design not so interesting for the 
average client?

>> I think that the former two are one specification (in which the
>> Client-to-Server portion and Server-to-Server portions might be overlapping
>> subsets), and the latter a separate specification. It certainly shouldn't be
>> *required* for every implementation of the spec to implement the rich
>> content API.
> [walter] i also originally read the "social API" in the charter as a client-server API rather than a javascript library spec (more like the opensocial gadget APIs). is it thus the intention to actually go for these 3 layers? Should the charter be updated to clarify this?

personally, i read the "Social API" as actually being the JS variant, 
and just hoped that instead of driving a REST API via a JS API design 
(which has some risk to result in a not-so-great REST API), the group 
would approach things the other way around.

but in the end, the question is what interactions we want to enable. 
that's a discussion around functionality. whether you then want to do it 
by programming a JS client against a DOM API, or a REST client against a 
HTTP-based API really is a question of implementation preference, right? 
what matters most is the domain model in terms of interactions and 
representations, and that should be the starting point of the design.

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Friday, 1 August 2014 16:44:10 UTC