SENDER REST API

gistfile1.md

DRAFT 0.0.1 !!

WARNING: YES... this is NOT complete, YET..... and it ONLY discusses a broadcast ...

For sending native push messages (see shared gist details), I want the following REST API for sending messages:

Message format

The generic message format of the payload, is a simple map:

{
  "message": {
    "key": "value",
    "key2": "value2"
  }
}

special keys

For iOS there are a few important key words, like alert, sound or badge. If the message contains them the API ensure it's honored properly. The keywords for iOS are NOT send to Android, as alert, sound or badge has NO meaning there. Android is just happy receving a simple map... not more. Rest (e.g. playing sounds) is up to the application developer....

Disussion

• Should we send something like sound to Android as well? Or should we ignore it?
• Should we try to invent a 'generic' Message format ? How to honor (iOS specifics) ?
• Could be done in a later iteration - improving the message format

To large messages

When a message is to large, it's not submitted. The Apple and Google Push Networks have different requirements about the actual lengt

#Sending

There are three different types of sending:

• broadcast to all mobile applications of a PushApp
• send message to specific device(s)
• send message to specific user(s) (Installations in the above linked gist)

Send a broadcast message to all application

To send a message to all mobile apps of one Push Application, the following is required:

Submit a HTTP POST against /sender/broadcast/132445213212312, with a body like this (yes... API key headers are missing):

{
  "message": {
    "key": "value",
    "key2": "value2"
  }
}

The above goes to all installed mobile apps, that are registered with one Push application (ID: 132445213212312), for instance:

• Android free
• Android paid
• iOS free
• iOS paid

Send message to a filtered list of applications

To send a message to a selected list of mobile apps of one Push Application, the following is required:

Submit a HTTP POST against /sender/apps/132445213212312, with a body like this (yes... API key headers are missing):

{
  "mobileApps": ["ow0e19092341", "dsc232012123"]
  "message": {
    "key": "value",
    "key2": "value2"
  }
}

The above goes to all installed apps of the following mobile apps, that are registered with one Push application (ID: 132445213212312), for instance:

• Android paid (ow0e19092341)
• iOS paid (dsc232012123)

Send message to a filtered list of users (installations)

To send a message to a selected list of MobileApplicationInstances (aka Installations) of mobile apps of one Push Application, the following is required:

Submit a HTTP POST against /sender/installations/132445213212312, with a body like this (yes... API key headers are missing):

{
  "instances": ["081912312331231", "2134terfds12"]
  "message": {
    "key": "value",
    "key2": "value2"
  }
}

The above goes to exactly two installed apps, that are registered with one Push application (ID: 132445213212312), for instance:

• User Bruno (Android-premiumPLUS client: 081912312331231)
• User Kris (iOS-premiumPLUS client: 2134terfds12)

This all looks good.

For the discussion points about message format.

Should we send something like sound to Android as well? Or should we ignore it?

Will Android ignore that info if it is sent? If so, I would say go ahead and send it if it's easier for the user.

Should we try to invent a 'generic' Message format ? How to honor (iOS specifics) ?

I would vote yes for this. We could then provide a shortMessage and longMessage keys where short message would be used for both iOS and Android unless a longMessage is present, then the longMessage would be used for android since it can take a bigger message. This could also address your point on sending sound to Android since we would be processing the messages before send so those items could be removed before sending to Android.

Should we send something like sound to Android as well? Or should we ignore it?

Will Android ignore that info if it is sent? If so, I would say go ahead and send it if it's easier for the user.

Well - if we send that (e.g. {"sound" : "default", .............}) to Android it could be picked up by the Android APP dev, but if he wants to play a sound - he has to code that (similar with the notifcations) - On iOS you just define {"alert":"YO MESSAGE DUDE"} and this is visible on your phone.

IMO it does not cause any harm to send things like that; Android gets the map with all the details and can pick the info it likes - makes sense ?

Should we try to invent a 'generic' Message format ? How to honor (iOS specifics) ?

I would vote yes for this.

Cool - we can focus on the details in a bit :)