1:42 p.m.
On Wed, Mar 20, 2013 at 1:31 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Mar 20, 2013, at 6:43 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
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 …
I agree that different endpoints makes sense, especially if a user is only
interested in iOS devices for example and so only build an app that works
on iOS, since this would allow for easy registration of a single type of
application. I would however like to see, and believe users would like to
see, some sort of unified API so that they only have register an app once
for both Android and iOS. Maybe this won't be an issue once we have more
than just a REST interface but just wanted to throw it out there.
Like a post to "/applications
where the payload is:
{
// push app properties
"description":"just a test",
"name":"TestApp",
// REQUIRED Apple Push Network props:
"cert":"CERT_UPLOAD_VAL",
"passphrase": "top-secret",
REQUIRED GCM Push Network props:
"google-api-key": "dsdsaadsadsdasadsdsa"
}
and the 201 Response could look like:
{
"id":"PushAppKey"
"apps":[
{"iOS-ID":"adda213213"},
{"android-ID":"454dda213213"},
]
}
This UBER :) API could work, for really just one "server side" abstraction,
that has exaclty ONE iOS and one Android APP (of course the request body
of the POST could contain arrays for different CERTS, passphrases,
API-Keys).
For a convenience we surly can have that - Is that what you mean ?
-M
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(a)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.
> <https://gist.github.com/matzew/ec5c3c2dfa955c58c328#overview>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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf