[aerogear-dev] Fwd: [Aerogear-dev] Survey of web apis for persistence and basic security

[Douglas Campos]

Begin forwarded message:

> From: Marko Strukelj <mstrukel at redhat.com>
> Subject: Re: [Aerogear-dev] Survey of web apis for persistence and basic	security
> Date: August 31, 2012 5:46:46 PM GMT-03:00
> To: Jay Balunas <jbalunas at redhat.com>
> Cc: aerogear-dev <aerogear-dev at redhat.com>
> 
> This is great. More inline ...
> 
> ----- Original Message -----
>> 
>> 
>> First, thanks for writing this up!! Its useful to see this all on one
>> place.
>> 
>> 
>> Data-binding to classes or generic property bags?
>> 
>> * We want to take advantage of JavaEE, BV, etc... I think binding to
>> classes will be important for this.
>> * This does lead to portability concerns, because while Android is
>> Java, iOS and others are not
>> ** We'll need a metamodel for this, and should to things like OData
>> and others
>> 
> 
> I see this as purely client API concern. With either approach the data then has to be marshalled into some data exchange format for shipping to the server, and the opposite operation when received from the server. The most natural format for aerogear-client to REST is JSON I dare say. 
> 
>> 
>> How to handle data relations?
>> * One of the best ways I've seen of handling this is to link to have
>> options for some depth to be included
> 
> Yes, client could send a filter as part of fetch operation. Default could be everything. And then you could exclude.
> {exclude: "User.Address"}
> 
>> * Any circular, or deep relationships should be a "link" object of
>> some sort that points to the resource if needed
>> 
> I think for synchronization optimizations like this make sense. Not sure if it makes sense for simple fetch, where you already filter out data you don't want with exclusion filter. Having duplicates of full structure i.e.
> 
>  city: {name: "San Francisco", zip: "94103"} 
> 
> as opposed to reference
> 
>  city: {ref: {type: "City", id: "94103"}}
> 
> Makes client side much simpler to process the data.
> When references are involved you have multiple ways of handling that. You can include one copy of the entity for each reference in the response so that you make sure the data is fresh. Or you may leave to the client to decide whether to use locally cached data (maybe good enough from client point of view) of whether to request the latest from the server, which is a really a sync operation to make sure you have fresh data on the client. But when you don't do this as part of a single request/response you can't have tx consistency for the data.
> 
> Having references gives rise to many options and makes things quite more complex :)
> 
>> 
>> How to handle binary data?
>> * Blobs can be hashed, and sent as is, but would likely need a
>> header/mimetype
>> 
> 
> I imagine blobs are URL resources, so in JSON just include a URL to the blob.
> 
>> 
>> Explicit class schemas or schemaless
>> * I want to make sure we're talking about the same thing, can you
>> explain more?
>> 
> 
> You mean something like JSON Schema (analog to xsd in JSON world)? If you want automatic entity class generation for access to REST endpoint that has some data, then you need some schema which describes the data. 
> 
>> 
>> How to best handle local caching + sync?
>> * This would be partially based on the client, but also on the
>> serverside.
>> * For our initial impl basic local caching is fine (or we leave it to
>> the end user for now)
>> * Sync, and more advanced offline syncing can wait for phase 2 imo
>> 
> Yes, that's a big topic :)
> 
>> 
>> Provide atomic counters? (most of these libraries do)
>> * Yes, we'll likely need something like this.
>> * Matthias - do you have any previous experience with this
>> requirement?
>> 
> You mean to use autoincrement counters for IDs? You can't generate those on the client so whenever you need to increment that's a serverside operation. And on the server that's a single node operation - you need a cloud-wide singleton that handles this for all clients... That's a big downside, as your app now has a scalability chokepoint. I think for IDs it's best to use GUIDs where you don't have some other semantic id. They are globally unique so you can generate them on the client (presuming they are correctly implemented, and that there's a good random generator used :).
> 
>> 
>> Manage clients with API keys?
>> * That is a common way to do this
>> * We should outline the different options
>> 
> API keys are used to control public access to certain server endpoints and provide ability for QoS, right? An API key is tied not to a single user or a single client device but to client app. And requires quite an advanced infrastructure with management UIs ... and it's for consumers of the APIs to use, and for providers of APIs to have monitoring tools and administration tools. I think that's something way out into the future ...  Or maybe you have something else in mind :) 
> 
>> 
>> Other questions:
>> 
>> 
>> Model/entity based client storage, or database replication?
>> 
> Another big one :)
> 
>> 
>> On Aug 31, 2012, at 2:41 PM, Jay Balunas wrote:
>> 
>> 
>> 
>> Hi All,
>> 
>> 
>> I'm posting Glen's gist on his review of existing apis for BaaS
>> operations - https://gist.github.com/3495006
>> 
>> 
>> Any comments and feedback welcome!
>> 
>> 
>> -Jay
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/aerogear-dev

-- qmx