Background

The Messaging Gateway was built for the purpose of providing a single unified API; while abstracting away the complexities of integrating with various Telco SMSCs and MMSCs, The API aims to be simple and easily implementable by its API Client users.

The API aims to adhere to the REST architectural styles and RESTful principles.

System Architecture

Assumptions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

The following are the assumptions on the User / developer:

1. Familiarity with HTTP concepts (e.g. urls, methods, status codes, user_agents, webservers, etc.)
2. Familiarity with REST concepts (e.g. resources, representations, etc)
3. Access to physical resources and infrastructure, including but not limited to servers, ip-addresses, domains and other network resources; such are needed to support the deployment of API clients and endpoints for the User.
4. Capability to develop, test, and run an API Client; usually in at least one of the many programming languages / platforms / frameworks with HTTP client support libraries.
5. Capability to develop, test, and run Endpoints; usually involving web servers and the dynamic backend code handling of HTTP requests.

Connection Handling

The following are the general network connection policies / properties:

1. Request authentication scheme is Basic Access Authentication (see Appendix).
2. HTTP requests made by an API Client to the MGW Endpoint MUST be send via secure transport (e.g. HTTPS).
3. HTTP requests made by an API Client to the MGW Endpoint SHOULD be validated by the server.
4. HTTP requests made from the MGW user-agent to the User’s Endpoint MUST be signed.
5. HTTP requests made from the MGW user-agent to the User’s endpoint SHOULD be handled as quickly as possible, with the messages queued – i.e. async delivery. (default timeout is 20 seconds).
6. HTTP requests MAY be rate-limited.
7. HTTP requests with response status errors (code 5xx) MAY be subject to retries (default none).
8. HTTP requests with response status errors (code 5xx) MAY be subject to backoff.
9. HTTP connections MAY remain open via the HTTP Ketaepalive mechanism; subject to timeouts (default 20 seconds).