Here is the REST API for "Push App" (+mobile app) registrations:Questions:The post to "/applications/das231432qwdsa2/iOS" and/or "/applications/das231432qwdsa2/android" are different (payload-wise)....Not sure if that is best solution.... However, we need to differentiate between different "mobile os variants" anyways....My (CURRENT) feelings is that a different "endpoint" is better instead of an ugly, large - but generic - API that does everything, and the server figures out what type of mobile app has been registered …
NEXT: Device Registrations + Sender Endpoints(Followed by "management" (get, put, delete.....)Greetings,Matthias_______________________________________________On Tue, Mar 19, 2013 at 4:45 PM, Matthias Wessendorf <matzew@apache.org> wrote:
Hello,
here is the 'overview' section of the Unified push....:
AeroGear Unified Push (DRAFT 0.0.2)
This is an early version of a 'spec' for the AeroGear Unified Push server.
Overview
The Unified Push solution contains the following components:
- Native Push Component: sends native push message to registered apps
- Web Push Component: sends web push message to online client (e.g. WebSocket/SockJS clients)
- Client SDK API
- Native Push Client for iOS
- Native Push Client for Android
- Web Push Client for JavaScript
Details are discussed on the each of the different components
NOTE: LINK need to be enabled :) :)
HOWEVER.......
Here is what I'd like to add to the home page for the native push component - based on last weeks discussion:
https://gist.github.com/matzew/69d33a18d4fac9fdedd4
PLEASE comment on the gist....
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev