[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 10:04:00 EDT 2013
Yep,
I understand, like you I'm not sure what is the best choice (honestly I
think yours is better), I just wanted to put all the options on the table,
should be great to hear other opinions.
Seb
On Wed, Mar 20, 2013 at 3:00 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>
>> 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
>
> _______________________________________________
> 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/f750e14d/attachment-0001.html
More information about the aerogear-dev
mailing list