[aerogear-dev] REST API - First thoughts: (Re: [AG Unified Push] Overview and NATIVE Push spec)

Wed Mar 20 09:13:13 EDT 2013

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",
  description: "desc1",
  // I would recommend wrapping these in platform names in case key names
ever change and match
  ios: {
      [
          {cert: "certval1",
          passphrase: "passphrase1"},

         {cert: "certval2",
          passphrase: "passphrase2"}
   ]
  },
android: {
    [
       {"google-api-key": "key1"},
       {"google-api-key": "key2"}
   ]
}
 },
 {
  name: "app2",
  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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130320/283385b0/attachment.html 