[aerogear-dev] REST API - First thoughts: (Re: [AG Unified Push] Overview and NATIVE Push spec)
Sebastien Blanc
scm.blanc at gmail.com
Wed Mar 20 09:54:15 EDT 2013
Totally agree,
So let's focus again on the second one : post /app/:ID:/iOS and your remark
that we have different payloads. It's hard to decide, just wondering about
API maintenance (more API documentation etc ) potential issues when we
will be adding new devices (BB, Windows, Facebook phone;) ), could
something like that works :
/applications/das231432qwdsa2/register
{
"deviceType": "ios" // could be "android", "bb"
"settings" : {
// wildcard key/value pairs
}
}
We keep here a generic API but will maybe have more work on the backend
side.
Just a suggestion.
Seb
On Wed, Mar 20, 2013 at 2:41 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>
> On Wed, Mar 20, 2013 at 2:13 PM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>
>> Maybe we can have this UBER api but we still need to have the "atomic"
>> service to be able to add a mobile apps afterwards, no ?
>> Second point is, if I understood it well from the previous gists and
>> discussion : inside a same device type, let's say iOS, there can multiple
>> mobile apps pointing to the same push app (freemium/premium etc ...). So we
>> need an extra array :
>>
>>
>> [
>> {
>> name: "app1",
>>
> .....
>
>> name: "app2",
>>
>
> ... not sure if I really want to register the entire app store, with one
> HTTP POST :)
>
> what u suggested is basically, one POST registers:
> -Foo-Inc's HR app (and various iOS/Android)
> -Foo-Inc's CRM app (and various iOS/Android)
> -Foo-Inc's WHAT-NOT-APP app (and various iOS/Android)
> ...
>
> I think that a POST to /applications, should only register ONE push app
> (however, with different mobile variations (paid/free))
>
>
> -M
>
>
>
>
>
>> description: "desc2",
>> // I would recommend wrapping these in platform names in case key names
>> ever change and match
>> ios: {
>> [
>> {cert: "certval3",
>> passphrase: "passphrase3"},
>>
>> {cert: "certval4",
>> passphrase: "passphrase4"}
>> ]
>> },
>> android: {
>> [
>> {"google-api-key": "key3"},
>> {"google-api-key": "key4"}
>> ]
>> }
>> }
>> ]
>>
>>
>>
>>
>> On Wed, Mar 20, 2013 at 1:54 PM, Kris Borchers <kris at redhat.com> wrote:
>>
>>>
>>> On Mar 20, 2013, at 7:42 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>
>>>
>>> On Wed, Mar 20, 2013 at 1:31 PM, Kris Borchers <kris at redhat.com> wrote:
>>>
>>>>
>>>> On Mar 20, 2013, at 6:43 AM, Matthias Wessendorf <matzew at 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 ?
>>>
>>>
>>> Yep, that is pretty much what I meant, and would be in favor of passing
>>> an array of applications instead of an array of certs, etc. which would
>>> allow for multiple applications on multiple platforms like this:
>>>
>>> [
>>> {
>>> name: "app1",
>>> description: "desc1",
>>> // I would recommend wrapping these in platform names in case key
>>> names ever change and match
>>> ios: {
>>> cert: "certval1",
>>> passphrase: "passphrase1"
>>> },
>>> android: {
>>> "google-api-key": "key1"
>>> }
>>> },
>>> {
>>> name: "app2",
>>> description: "desc2",
>>> // I would recommend wrapping these in platform names in case key
>>> names ever change and match
>>> ios: {
>>> cert: "certval2",
>>> passphrase: "passphrase2"
>>> },
>>> android: {
>>> "google-api-key": "key2"
>>> }
>>> }
>>> ]
>>>
>>>
>>> -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 at 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at 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_______________________________________________
>>>
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at 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
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130320/886b231c/attachment-0001.html
More information about the aerogear-dev
mailing list