Here is the REST API for "Push App" (+mobile app) registrations:

https://gist.github.com/matzew/2da6fc349a4aaf629bce


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