[aerogear-dev] REST API - First thoughts: (Re: [AG Unified Push] Overview and NATIVE Push spec)
Matthias Wessendorf
matzew at apache.org
Wed Mar 20 10:00:54 EDT 2013
> when we will be adding new devices (BB, Windows, Facebook phone;) ), could
> something like that works :
>
You still need some server side logic, to understadn the windows (for
instance) mapping of the attributes.
IMO no matter if the decision of the TYPE is done _inside_ of the payload,
or on different endpoint/subendpoint.
In vert.x the RouteMatcher is already generic:
rm.post("/applications/:key/:variant", new Handler<HttpServerRequest>()
So... if theere is a post against "/application/12345/windows" - the
"parser decides based on "variant". Your way it would check based on
payload type;
Again - I am not against it - nor I am for that :) I am just ... not sure
if "wildcards" are always that great...
>
> /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
>>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130320/8542f638/attachment-0001.html
More information about the aerogear-dev
mailing list