I took a quick look at the Android API. Below are a few questions:
- Is the class 'just' a util, that offers static methods? If so,
should have a private ctor and be final (since a private default ctor
prevents inheritance anyways)
- is the API_KEY really needed? Not sure, but I think that (the
API_KEY) is _perhaps_ something on-top of a networking client lib,
needed when entering the real 'BaaS' market, where our lib. is used
against a (specific) 'backend provider'.
- related to the API_key, I think the X-AeroGear-Client header needs
to be defined/discussed - but IMO the AeroGear client lib should work
also without such a key, when accessing a simple JAX-RS (read:
RestEasy) service; Of course, when 'cloud provider' start using our
bits, something like API_KEY is a must.
- the 'delete' is public; the others (e.g. post) not...
- how to update an existing item?
For instance in JS/iOS we use save which does an 'add' if there is no
_id_ or issues an 'update' if the entity already exisits (e.g. has an
There is no concept of a 'pipeline', but I guess (at least for now) on
"Java" (aka Android) a typed list (e.g. List<Pipe> pipeline;) is good
But on the other hand, than it's up to the user of the api to 'manage'
all the pipes (server connections).
Just got my new mac book and i need some advice on some system setup.
Things i'm planning on:
I'm thinking of SublimeText2 as an editor. I'm interested to see what the
something more lightweight.
What are some other things that i should be installing to get setup up
Figured this would be a good guide for new team members and users <--
stole this thought from Jay :)
I was thinking on how to start this conversation on server contracts, so let's start with an example for a resource named "car" - all interactions are 'application/json'.
We talked on irc about how to maintain the bare minimum that would give us full agnostic server backends, and I've tried to limit as CRUDL - CRUD + List without pagination :)
C POST /cars
R GET /car/1
U PUT /car/1
D DELETE /car/1
L GET /cars
Glen commented on irc that this would introduce coupling between the client and the server - but the point is that the endpoint style can and should be configurable in several levels:
- always_plural? (/cars everywhere) 
- do we support batch operations? (as suggested by )
- logic name (/vehicles should be interpreted as "cars")
- read-only routes?
The point is, we can and should adapt to the most common scenarios - so an user should be able to use /signup instead of /register for auth endpoints - and there's what is a must for us IMO.
The user is using a <insert your technology here> server? if he supports http sessions we should be able to authenticate him, and here is where our challenge lies - being "inclusive" without making our APIs lame :)
So, we need to figure out what is more common, and make this the default (or convention), while still allowing our users to choose different/weird conventions for their endpoints.
(Before I forgot, Glen asked about pagination too, and I think this should be layered on top of this basics, as in this case there is no standard way to do it)
I was talking with kris today about JS formatting, and he showed me this .
Even if I hate some of the proposed styles, having consistency wins over personal preferences, and we don't have decent JS autoformatters, AFAIK.
Any objections to following this as our guideline for JS code?
Hey everyone, I just wanted to let you know I have been doing a little research around generating id's on the client side. I have found a little JS utility lib that I am thinking about using that generates RFC4122 compliant UUIDs. That library is here http://www.broofa.com/Tools/Math.uuid.js if you are interested. Bruno thought it would be a good idea that I send this out for everyone as it may be a good idea to see what is available in the Android and iOS world in terms of generating similar id's.
I have been thinking about this a bit lately and am also hoping to get people's thoughts on whether or not this may be overkill. The reason I say that is that really the only reason you would need such a unique id is if there will be a chance of something else (another client, server, etc.) generating an id for a piece of data that would conflict with this one. What I was thinking though is that is only an issue at sync time. As long as you know the id is unique in the client, and the status of that piece of data (new, modified, removed), then at sync time, you can rectify those id's that are out of sync with what is generated at the server and you have one point of id generation.
Would really appreciate others' thoughts on this.