If the MAX did present such an API, we would use it mainly to retrieve SMS’s. The following API would suit our use-case:
In the following polling-based API, the MAX simply knows of set of SMS’s which have arrived to the SIM by a certain time , and have not yet been deleted. The timestamp format could be TAI64, as a reasonable default.
Request: GET /sms
Response: 301 /sms/<till-timestamp>
… tells an inquirer what the ‘latest timestamp’ is
Request: GET /sms/<till-timestamp>
Response: 200 text/xml
… gets the yet-undeleted messages up to that timestamp
Request: DELETE /sms/<till-timestamp>
Response: 200
(no body)
… deletes the messages up to that timestamp
This means that messages arriving to the SIM while the application is interacting with the gateway, are unaffected by the delete. The explicit delete by the consumer of the messages ensures that messages are never ‘lost’.
Additionally, it would be neat to specify some ‘webhooks’, where the MAX attempted to notify an application that messages were available. For example, given a configuration string of:
https://10.2.24.84/app/noticesms?when=$timestamp
the MAX would either give, as configured:
POST /app/noticesms?when=<till-timestamp>
… messages follow in the body
… IF the app responds with 200 - OK, then the MAX takes that as ‘safe to delete’
or
GET /app/noticesms?when=<till-timetamp>
… with no body
The MAX never re-attempts the hook (until more messages arrive), but would obviously log the attempt and its result.
These are just off the top of my head. I will report back if, having investigated SMS gateway API’s more, it starts to seem like a dumb idea.
If the MAX doesn’t provide this, my scenario would be solved by a separate Android device acting as an SMS gateway. However, that’s:
a) an extra device to power
b) that is somewhat unpredictable (since updates get pushed to it by the app stores)
c) an extra SIM to subscribe to, when we could simply have the number and the data on the same SIM inside the MAX
regards,
David.