UnifiedPush: API for sending notifications to SimplePush clients/channels
by Matthias Wessendorf
Hi,
for my upcoming work on
AGPUSH-320<https://issues.jboss.org/browse/AGPUSH-320> I
did think a bit about our current API, especially how the SimplePush part
is looking today...
When sending a (SimplePush) notification via the UnifiedPush today it looks
like:
curl -3 -u "{PushApplicationID}:{MasterSecret}"
-v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{
"simple-push": {
"SomeCategory":"version=123",
"anotherCategory":"version=456"
}
}'
https://SERVER:PORT/CONTEXT/rest/sender
This (currently) implies the fact that only *one* category is possible, per
channel/device (will change, as mentioned in above JIRA). But... I think
this can lead to some really stupid use-case:
"simple-push": {
"european_financialNews":"version=456",
"earthquake_bayarea":"version=789"
}
A mix like that will not happen, I'd assume... But for me the point is...
it really does not make sense to send a few notifications for *totally
different* channels, on *ONE* request...
This is similar to something like where you send *ONE* notification to two
(or more) totally different native apps (e.g. weatherApp-iOS andWhatsApp).
Not sure what kinda back that really wants
<https://github.global.ssl.fastly.net/images/icons/emoji/smile.png>
My suggestion is to change the API a bit, and make it more like we treat
the native Android/iOS clients (besides the version limitation from
SimplePush):
curl -3 -u "{PushApplicationID}:{MasterSecret}"
-v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{
"category" : ["German Bundesliga", "UEFA ChampionsLeague"],
"message": {
"alert":"Goal by Marco Reus!",
"sound":"default"
},
"simple-push": "version=someVersionNumberString"
}'
https://SERVER:PORT/CONTEXT/rest/sender
The simple-push key just takes the *version=FOO* thing (or maybe just the
versionNumberString...), instead of submitting a map, where we pass *
different* versions for *different* channels.
The rest is pretty much similar to what we already do today (at least for
Android/iOS):
- We apply some criteria (sure *this* example already has multiple
categories...)
- Based on the different criteria we find all the *Installations* (==
devices/connected clients) we want.
*Note:* If no criteria has been specified, we deliver the message (for SP
the given version) to all installations of all registered variants... (like
we do it already today)
Any thoughts ?
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years, 1 month
UnifiedPush Server = Resetting MasterSecret (PushApp) and Secret (Variant)
by Matthias Wessendorf
Hello,
For [1 <https://issues.jboss.org/browse/AGPUSH-209>] I want to discuss a
RESTful API for resetting the (Master)Secret of a PushApp and/or a Variant.
Initially I'd like to propose an empty PUT request against an 'reset'
endpoint, specific to the ID of the PushApp/Variant (see
[2<http://staging.aerogear.org/docs/specs/aerogear-push-rest/PushApplication/>]
and [3<http://staging.aerogear.org/docs/specs/aerogear-push-rest/Variants/Android/>
]).
To give a congrete example: Resetting the Secret of an Android Variant
would result in a PUT against this URL:
https://SERVER:PORT/CONTEXT/rest/applications/{pushApplicationID}/android...
The CURL command would look like:
curl -3 -v -H "Accept: application/json" -H "Content-type: application/json"
-X PUT
https://SERVER:PORT/CONTEXT/rest/applications/{pushApplicationID}/android...
The response body to that *PUT* request contain (JSON) details about the
specific Android Variant (using Android as an example here):
{
"id":"402880e43fa95bb3013faf3c41b40005",
"name":"Android App",
"description":"The Android Variant",
"variantID":"04e9f747-d256-4a24-a0ac-29b9a15e37b1",
"secret":"70135d26-696d-426a-8183-e1fd0fcb86fe",
"developer":"admin",
"instances":[],
"googleKey":"My Google API Key",
"projectNumber":"My Project Number / Sender ID"
}
<https://gist.github.com/matzew/7d78eb091f6ca0fa01bb#admin-ui>Admin UI
On the Admin UI the *HTTP PUT* request could be triggered through a button,
the actual execution would happen after giving "approval" on a
'confirmation' button...
On the long run, we could make it more 'complex', e.g. sending an email,
containing an URL to give approval to the reset etc - but for now, I'd like
to keep the reset simple..
Any thoughts ?
[1] https://issues.jboss.org/browse/AGPUSH-209
[2]
http://staging.aerogear.org/docs/specs/aerogear-push-rest/PushApplication/
[3]
http://staging.aerogear.org/docs/specs/aerogear-push-rest/Variants/Android/
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years, 1 month
Planing: UnifiedPush Server: 0.9.0 (mid Nov)
by Matthias Wessendorf
Hi,
for the main "server side" items, I thought about these to be included for
the 0.9.0 release:
AGPUSH-110 - Message Format: Honor Time To Live options for APNs / GCM
AGPUSH-208 - Reset (Master)Secret of PushApplication/Variant
AGPUSH-320 - Let device registrations be in multiple categories at once
AGPUSH-365 - iOS 7 silent push notification
AGPUSH-374 - Reflect pushEndpoint change in SimplePush/UP guide
Are you missing something here ?
BTW. on the Admin UI, I can see that minor tweaks might get in as well (as
needed). Also, perhaps the User Management as well? Sebi/Luke, any thoughts
?
Greetings,
Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years, 1 month
