Documentation à destination des utilisateurs

Introduction

Si la majeure partie des fonctionnalités de RaspiSMS s'utilise naturellement sans la moindre documentation, il en est une ou deux qui nécessitent quelques explications.
Voici donc ici une rapide aide afin que vous puissiez facilement utiliser ces fonctionnalités.

Commandes par SMS

De toutes les fonctions, celle qui demande le plus d'explication est sans aucun doute l'envoi de commandes par SMS.
Cette fonctionnalité vous permet de contrôler votre Raspberry Pi à distance via votre téléphone, par le simple envoi de SMS.

Description

Afin de pouvoir faire effectuer une action à votre Raspberry Pi par SMS, vous devez dans un premier temps créer une nouvelle commande.
Cette commande devra avoir un nom, qui sera utilisé lors de l'envoi du SMS pour savoir quelle commande appeler (il est donc possible de programmer autant de commandes différentes que vous le souhaitez).
De plus, cette commande devra pointer sur un script en ligne de commande (dans le langage de votre choix, bash, python, php, perl, etc.). Ce script sera celui appelé lors de la réception du SMS.
Ce script sera donc appelé par l'utilisateur faisant tourner votre serveur web (par défaut "www-data"). Vous devez donc lui donner des droits permettant son exécution par "www-data".
Ce script devra être placé dans le dossier "scripts" situé à la racine de RaspiSMS.
Enfin, cette commande possède un réglage spécifiant si le niveau "administrateur" est nécessaire pour l'exécuter. Si ce paramètre est défini comme vrai, seul un utilisateur de RaspiSMS qui est administrateur pourra déclencher cette commande par SMS.

Format d'un SMS de commande

La question la plus importante sur les commandes par SMS est bien sûr ce que doit contenir le SMS de commande.
Afin de pouvoir lancer une commande par SMS, ce dernier devra contenir, le nom de la commande et les identifiants d'un utilisateur (l'email et le mot de passe).
Pour fournir des informations, le SMS doit correspondre à un certain format. Il peut en revanche contenir d'autres choses que ces trois données, et ces dernières ne sont pas assujéties à un ordre particulier.
Voici donc le format que devra respecter un SMS de commande.

[<nom command>:<si besoin parametres supplementaires passés à la commande>][login:<email user>][password:<password user>]

Documentation à destination des développeurs

Introduction

RaspiSMS est un projet qui a été initialement créé par le site http://raspbian-france.fr. Ce projet est distribué sous licence GNU/GPL, afin de permettre à tous de le réutiliser.
Par conséquent, il nous semble important de fournir aux possibles développeurs souhaitant utiliser et/ou modifier RaspiSMS, une documentation, même légère.
Soyons honnête les développeurs adorent avoir de la documentation sur un outil, détestent l'écrire, jurent tous de le faire, et ne le font jamais. Par conséquent, nous avons décidé d'écrire une documentation pour votre bonheur, et nous avons décidé qu'elle serait légère pour le notre.
Nous allons donc vous présenter les schémas de la base de données, le modèle MVC sur lequel repose RaspiSMS et l'API RaspiSMS, qui est sans doute le point le plus important.

Base de données

RaspiSMS utilise une base de données MySQL INNODB. Vous verrez plus loin comment accèder à la base via le modèle MVC. Ici nous verrons seulement les différentes tables et pour chacune une rapide description.

Settings

La table "settings" contient l'ensemble des réglages de RaspiSMS.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique du réglage
name VARCHAR(50) No No No Nom du réglage
value VARCHAR(1000) No No No Valeur du réglage

Receiveds

La table "receiveds" contient l'ensemble des SMS reçus.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique du message
at DATETIME No No No Date de réception du message
send_by VARCHAR(12) No No No Numéro ayant envoyé le message
content VARCHAR(1000) No No No Contenu du message
is_command BOOLEAN No No No Note si le message correspond à une commande du système.

Sendeds

La table "sendededs" contient l'ensemble des SMS envoyés.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique du message
at DATETIME No No No Date d'envoi du message
target VARCHAR(12) No No No Numéro à qui a été envoyé le message
content VARCHAR(1000) No No No Contenu du message
before_delivered INT No No No Compteur de SMS "Delivered" à recevoir avant que le SMS soit considéré comme délivré
delivered BOOLEAN No No No Indique si le message a été reçu par le destinataire
failed BOOLEAN No No No Indique si une erreur est survenue lors de l'envoi du message

Scheduleds

La table "scheduleds" contient l'ensemble des SMS programmés.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique du message
at DATETIME No No No Date à laquelle doit être envoyé le message
content VARCHAR(1000) No No No Contenu du message
flash BOOLEAN No No No Indique si le SMS est un SMS Flash
progress BOOLEAN No No No Indique si le message est en cours d'envoi

Contacts

La table "contacts" contient l'ensemble des contacts.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique du contact
name VARCHAR(100) No No No Nom du contact
number VARCHAR(12) No No No Numéro du contact

Groups

La table "groups" contient l'ensemble des groupes.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique du groupe
name VARCHAR(100) No No No Nom du groupe

Commands

La table "commands" contient l'ensemble des commandes lançable par SMS.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique de la commande
name VARCHAR(25) No No No Nom de la commande
script VARCHAR(100) No No No Chemin du script (depuis le dossier "/var/www/RaspiSMS/scripts")
admin BOOLEAN No No No Indique si il faut être admin pour pouvoir lancer la commande

Events

La table "events" contient l'ensemble des évènements survenus.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique de l'évènement
type VARCHAR(25) No No No Type d'évènement survenu
at DATETIME No No No Date à laquelle est survenu l'évènement
text VARCHAR(255) No No No Texte de l'évènement

Users

La table "users" contient l'ensemble des comptes utilisateurs.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique de l'utilisateur
email VARCHAR(255) No No No Adresse e-mail de l'utilisateur
password VARCHAR(255) No No No Mot de passe hashé de l'utilisateur
admin BOOLEAN No No No Indique si l'utilisateur est administrateur

Groups_contacts

La table "groups_contacts" contient l'ensemble des contacts contenus dans un groupe.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique de la laison
id_group INT No No No Id unique du groupe
id_contact INT No No No Id unique du contact

Scheduleds_contacts

La table "scheduleds_contacts" contient l'ensemble des contacts auxquels un SMS programmé doit être envoyé.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique de la liaison
id_scheduled INT No No No Id unique du SMS
id_contact INT No No No Id unique du contact

Scheduleds_groups

La table "scheduleds_groups" contient l'ensemble des groupes auxquels un SMS programmé doit-être envoyé.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique de la liaison
id_scheduled INT No No No Id unique du SMS
id_group INT No No No Id unique du groupe

Scheduleds_numbers

La table "scheduleds_numbers" contient l'ensemble des numéros auxquels un SMS programmé doit-être envoyé.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique de la liaison
id_scheduled INT No No No Id unique du SMS
number VARCHAR(12) No No No Numéro de téléphone auquel sera envoyé le SMS

Transfers

La table "transfers" contient les SMS à transférer à un utilisateur

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique du transfer
id_received INT No No No Id du message à transférer

Sms_stop

La table "sms_stop" contient l'ensemble des personnes auxquelles ne pas envoyer de SMS STOP.

Nom Type Null Auto-increment Primary Description
id INT No Yes Yes Id unique du SMS STOP
number VARCHAR(12) No No No Numéro auquel ne pas envoyé les SMS

Modèle MVC

Lorsque nous avons développé RaspiSMS, nous avions envie d'un système léger. Nous avions par ailleurs commencé le développement d'un mini système MVC pour un autre projet.
Nous avons donc choisit de finir ce mini système MVC, et de l'intégrer à RaspiSMS.
Ce système est si simple, que vous pourriez aisément en comprendre l'utilisation par une rapide lecture du code de RaspiSMS. Cependant, nous allons tout de même faire un rapide tour sur son fonctionnement.

Principe général

Comme tout système MVC, le système de RaspiSMS vise à séparer les requêtes vers la base de données, le traitement des données ainsi récupérées, et leur affichage.
Par ailleurs, un système de routage très simple s'ajoute à l'ensemble.

Le fichier de configuration

Le système MVC utilise un certain nombre de constantes, qui sont définies dans le fichier de configuration « constants.php ».
Ce fichier permet notamment de définir les chemins utilisés par le système RaspiSMS, mais aussi les pages, et fonctions à appeler par défaut.
Il existe globalement pour les chemins deux types de chemins. Ceux internes au système, commençant par « PWD », et ceux côté client, commençant par « HTTP_PWD ».

Nous ne définirons pas l'ensemble des constantes, leurs noms étant suffisamment clairs, et le code étant commenté. Cependant, nous reviendrons rapidement sur 3 constantes particulières, qui définissent fortement le comportement interne du système.
Il s'agit des constantes définissant les méthodes et pages appelées par défaut.
Constante Description
DEFAULT_CONTROLLER Le nom du contrôleur à appeler par défaut si aucun autre contrôleur n'est fourni, ou si le contrôleur fourni n'est pas valide.
DEFAULT_METHOD La nom de la méthode qui sera appelée par défaut si aucune méthode n'est fournie, ou si la méthode fournie n'est pas valide.
DEFAULT_BEFORE La nom de la méthode que l'on cherchera à appeler avant toute autre fonction si elle est définie dans le contrôleur actuel.

L'autoload

Le système MVC utilise le système d'autoload de PHP. Celui-ci est défini dans « mvc/autoload.php ».
Cela signifie par exemple que vous n'aurez pas besoin d'inclure vos contrôleurs avant de les instancier.
Plus précisément lors de l'instanciation d'un objet, si la classe n'est pas trouvée dans le code, PHP va automatiquement aller chercher dans le dossier « controllers », puis le dossier « model », un fichier appelé <nom de l'objet instancie>.php.
Par exemple, si j'écris :

$richard = new geniousProgrammer();
Voyant que la classe « geniousProgrammer » n'est pas encore définie, PHP cherchera le fichier « controllers/geniousProgrammer.php », puis, si il ne l'a pas trouvé, il cherchera « model/geniousProgrammer.php », et inclura automatiquement le premier trouvé.
Si il ne trouve aucun fichier, une erreur surviendra.

Le routage

Le système de routage est assuré par la classe Router, qui permet d'analyser une route, (par exemple celle appelée par l'internaute), afin de la faire correspondre à un contrôleur, à une méthode, et possiblement à des données.
De façon générale, une route est construite en quatre parties, séparées par un « / » :

  1. L'adresse URL du serveur, avec éventuellement le chemin vers le dossier contenant RaspiSMS. Pour déterminer la partie de l'URL correspondant au chemin vers le dossier, le système se base sur la constante « PWD ».
  2. Le nom du contrôleur à appeler. Si il n'est pas fourni, on appelle celui défini par défaut.
  3. Le nom de la méthode à appeler. Si il n'est pas fourni, on appelle celle définie par défaut.
  4. Les paramètres qui seront transformés en paramètres GET. Ces paramètres adoptent le format <nom>_<valeur>. Cela permet de passer facilement des paramètres GET de façon optimisée pour le référencement.
Voici un petit schéma du découpage d'une route.
Découpage d'une route

Les contrôleurs

Les contrôleurs peuvent être considérés comme les différents modules du site.
Par exemple, l'ensemble des fonctionnalités relatives aux contacts sera contenu dans le contrôleur « contacts.php ».
Tous les contrôleurs doivent hériter de la classe « Controller ».
Cette classe « Controller » fourni quelques méthodes essentielles. Nous ne décrirons pas l'ensemble de ces méthodes, mais simplement les deux plus importantes :

Méthode Description
render Il s'agit sans doute de la méthode la plus importante. Elle permet d'afficher un template, en lui passant un certain nombre de variables (dans les templates, seul les variables passées ainsi sont accessibles).
generateUrl Il s'agit de la seconde méthode la plus importante. Elle permet de générer une adresse URL propre, absolue, construite à partir d'un contrôleur, d'une méthode, et de paramètres. Cette méthode peut être appelée depuis les templates, ce qui permet de très facilement gérer les URL.
Dans chaque contrôleur, vous devrez définir des méthodes qui correspondront à chaque page de l'ensemble des fonctionnalités que vient couvrir le contrôleur.
Par exemple, pour reprendre le cas des contacts, vous aurez une méthode « add », qui renverra la page d'ajout d'un contact.
Ces méthodes doivent être publiques, et devront bien souvent finir par l'appel d'un template afin d'afficher une page.
Vous pourriez avoir besoin d'écrire des contrôleurs qui ne soient pas appelables depuis internet par un utilisateur. Ce cas se présente notamment lorsque vous souhaitez créer des méthodes généralistes de validation de formats, ou encore des méthodes de chiffrement, etc.
Pour répondre à ce besoin le système MVC introduit un système très simple que nous nommons « contrôleurs internes ». Il vous suffit de créer un contrôleur qui contiendra les méthodes généralistes, et de lui donner un nom commençant par « internal ». RaspiSMS possède notamment un contrôleur nommé « internalTools », qui contient l'ensemble des outils utilisés par de nombreux contrôleurs (validation d'un numéro de téléphone, des dates, etc.).
Une fois ce contrôleur créé, il vous suffit de l'instancier et d'appeler la méthode depuis le contrôleur où vous en auriez besoin.
Méthode Description
getAll Cette méthode permet de récupérer l'intégralité d'une table dont le nom est passé comme premier argument. Par ailleurs, de nombreux arguments optionnels peuvent-être passés à cette requête, par exemple pour mettre en place un système de pagination. En voici rapidement la liste.
  • order_by (string) : Le nom du champ par lequel trier les résultats. (Par défaut, le tri est celui naturel de MySQL, soit l'id)
  • desc (boolean) : Indique si le tri doit-être fait par ordre ascendant (par défaut) ou descendant (si passé à vrai).
  • limit (int) : Nombre maximum de résultats à retourner. Si non défini, pas de limite.
  • offset (int) : Nombre de résultats à sauter. Si non défini, pas de résultat sauté.
RunQuery Il s'agit de la méthode la plus importante. C'est par elle que vous devez passer pour exécuter une requête PDO que vous avez préparée (certains cas très rares peuvent néanmoins vous imposer de ne pas utiliser cette fonction – principalement si vous devez fournir des paramètres en en spécifiant le type – et de passer directement via la méthode « execute » de PDO). Cette méthode peut prendre un certain nombre d'arguments, rapidement listés ici (seul le premier est obligatoire).
  • query (string) : La requête PDO à exécuter.
  • datas (array) : Le tableau des données à passer à la méthode « execute » de PDO
  • return_type : Le type de retour voulu. Une des constantes de la classe « Model » qui définissent les différents types de retours possibles. Par défaut « FETCHALL ».
  • fetch_mode : Le type d'association attendue. Une des constantes de la classe PDO qui définissent le type de sortie des méthodes de récupération des données. Par défaut « FETCH_ASSOC ».
En dehors de ces deux méthodes que vous serez amené à utiliser très régulièrement, quelques méthodes plus rarement utilisées mais parfois très utiles existent.

Le modèle

Le système de modèle est relativement simple.
Les requêtes sont écrites en SQL en passant par PDO. Nous choisissons volontairement de ne pas utiliser de système d'abstraction complexe comme l'on en rencontre dans de nombreux frameworks, ceux-ci ne nous ayant jusqu'ici jamais vraiment convaincus.
Il est d'abord constitué d'une classe principale, « mvc/Model.php », qui contient un ensemble de méthodes, permettant l'écriture et l'exécution de requêtes.
Il existe deux méthodes qui se démarquent particulièrement des autres, car elles seront appelées partout dans RaspiSMS.

Méthode Description
tableExist Prend en argument un nom de table, et vérifie si cette table existe ou pas.
fieldExist Prend en argument un nom de champ et un nom de table, et vérifie si le champ existe dans la table (en vérifiant avant si la table elle-même existe via la fonction tableExist).
generateInFromArray Prend en argument un tableau de valeurs (ces valeurs doivent être des chaînes de caractères, des chiffres, ou des booléens, mais pas des objets ou des tableaux), et génère une clause MySQL « IN » adaptée à PDO. La fonction retourne un tableau, avec une clef « QUERY », qui va être la clause « IN » à ajouter après la partie « <nom du champ> = » de la requête, et une clef « PARAMS », qui contient les valeurs pour la clause « IN » qui devront être passées à la méthode « execute » de PDO.
lastId Cette méthode retourne l'id de la dernière ligne insérée par PDO.
getColumnsForTable Prend en argument le nom d'une table, et retourne le nom des colonnes de cette table, sous la forme « <nom_1>, <nom_2>, <nom_3> ». Cette fonction permet notamment de faire un select de façon souple sur une table complète, sans avoir à utiliser l'opérateur « * ». Si la table fournie n'existe pas, la méthode retourne « false ».
Venant avec cette classe de base « Model.php », un second fichier « model/DataBase.php » contient l'ensemble des requêtes, et hérite de la classe « Model ».
Ce fichier contient chaque requête sous la forme d'une méthode. Il est possible de créer plusieurs fichiers dans le dossier « model », comme on le fait pour les contrôleurs, en définissant systématiquement une nouvelle classe pour ce fichier, et en la faisant hériter de la classe « Model », afin de rendre chaque fichier plus simple à maintenir. Cependant, cela implique d'utiliser à chaque fois un objet différent pour les différentes requêtes. Par soucis de simplicité, nous avons donc fait le choix pour RaspiSMS d'un fichier unique, « DataBase.php ».
Il est à noter que la classe « Model », et donc par extension la classe « DataBase » prennent une instance de PDO en tant qu'argument à la construction.
Enfin, notons qu'un objet DataBase « $db » est instancié par défaut dans « index.php », et donc accessible depuis n'importe quel contrôleur, pour peu que l'on déclare avant la variable $db comme étant globale dans ce contrôleur via la ligne.

Les templates

Le système MVC impose le découpage strict des requêtes, de leur traitement, et de leur affichage.
Cette troisième partie est le travail des templates.
Les templates sont donc les pages vues par l'utilisateur. Ils sont appelés par les contrôleurs, via la méthode « render », et ne peuvent afficher que les variables qui leurs sont internes, ou qui leurs sont passées via la méthode « render ».
Nous avons fait le choix de ne pas utiliser de langages de templating, considérant que PHP offre une syntaxe suffisamment claire si elle est bien utilisée pour ne pas avoir besoin de recourir à un tel procédé.
Par ailleurs, tout langage de templating impose une réduction des performances, que nous souhaitons éviter.
Afin d'inclure des parties récurrentes de sites (titre, menu, pied de page, etc.). Il vous suffit de créer un contrôleur interne (tel que « internalIncs ») gérant ces parties par des méthodes (par exemple une méthode footer), qui affichent des templates (comme le template « footer.php »), et d'instancier ce contrôleur au début du fichier, puis d'appeler à l'endroit voulu la méthode correspondant au bloc voulu.

Autres fonctions

Le système MVC peut embarquer quelques fonctions supplémentaires. Actuellement une seule autre fonction est disponible.
Il s'agit de la fonction « secho », pour « secure echo ». Comme son nom l'indique, cette fonction permet d'afficher de façon sécurisée une variable.
Cette fonction prend en paramètre une référence, et l'affiche si elle est définie. Par défaut, elle l'affiche en transformant les retours à la ligne en balises html « <br/> », en conservant les guillemets tels quels, et en considérant les variables équivalentes à false ou null comme définies.
Il est possible de changer tous ces comportements.

API

RaspiSMS a été pensé initialement dans le but d'envoyer facilement des SMS à un numéro depuis n'importe quelle plateforme, même avec une marge d'action extrêmement faible.
Le but était qu'à partir du moment où le système possède une connexion internet, il puisse envoyer un SMS en passant par la Raspberry Pi, sans avoir à installer quoi que ce soit.
Pour répondre à ce besoin, RaspiSMS intègre une API simple, qui permet la programmation d'un SMS à envoyer vers des numéros, des contacts, des groupes de contacts, voire les trois en même temps.
Partant du principe que l'appel à cet API doit-être permis depuis n'importe quel système, celle-ci peut-être appelée soit par la méthode GET, soit pas la méthode POST, sans que cela fasse la moindre différence.

Les paramètres

Voici la liste des paramètres de l'API. Pour chaque paramètre, il peut-être passé soit en GET, soit en POST (en cas de conflit le POST prendra toujours le pas sur le GET).
Le nom du paramètre correspond à la clef du tableau GET ou POST à utiliser.
Il est possible de passer les paramètres GET, comme montré dans la partie "routage" du modèle MVC.
Pour des raisons évidentes de sécurité, l'API nécessite une authentification. Pour cela, il suffit de lui passer en argument l'e-mail et le mot de passe d'un utilisateur de RaspiSMS.

Nom Description Obligatoire
email Adresse e-mail du compte à utiliser Oui
password Mot de passe du compte à utiliser Oui
text Texte du SMS Oui
date Date d'envoi du SMS au format Y-m-d H:i Non. Si non fournie, la date courante est utilisée
numbers Numéros de téléphone auxquels envoyer le SMS. Sous forme tableau, ou possiblement de chaîne pour un seul numéro. Non
contacts Nom des contacts auxquels envoyer le SMS. Sous forme de tableau ou possiblement de chaîne pour un seul numéro. Non
groups Nom des groupes auxquels envoyer le SMS. Sous forme de tableau ou possiblement de chaîne pour un seul numéro Non

Exemples de requêtes

Voici quelques exemples de requêtes, à travers différentes techniques. Toutes ces requêtes sont exécutées via CURL, mais elle pourraient aussi bien l'être par d'autres moyens. Par exemple, pour les requêtes GET, via la commande « wget ».
Pour chaque requête, une version de chaque forme (GET et POST) sera proposée. Par ailleurs, nous considèrerons qu'il existe sur votre installation de RaspiSMS un compte dont l'email est "admin@mail.tld" et le mot de passe "p455w0rd".

Création d'un message à envoyer immédiatement au 0612345678

#Requête GET traditionnelle
curl http://URLCIBLE/smsAPI/?email=admin@email.tld\&password=p455w0rd\&numbers=0612345678\&text=Texte%20du%20SMS%20à%20envoyer

#Requête POST
curl -X POST http://URLCIBLE/smsAPI/ -d 'email=admin@email.tld&password=p455w0rd&numbers=0612345678&text=Texte%20du%20SMS%20à%20envoyer'

Création d'un message à envoyer immédiatement au 0612345678, au contact "toto", et au groupe "team"

#Requête GET traditionnelle
curl http://URLCIBLE/smsAPI/?email=admin@email.tld\&password=p455w0rd\&numbers=0612345678\&contacts=toto\&groups=team\&text=Texte%20du%20SMS%20à%20envoyer

#Requête POST
curl -X POST http://URLCIBLE/smsAPI/ -d 'email=admin@email.tld&password=p455w0rd&numbers=0612345678&contacts=toto&groups=team&text=Texte%20du%20SMS%20à%20envoyer'

Création d'un message à envoyer immédiatement au 0612345678, aux contacts "toto" et "bidule", et aux groupes "team" et "friends"

#Requête GET traditionnelle
curl http://URLCIBLE/smsAPI/?email=admin@email.tld\&password=p455w0rd\&numbers=0612345678\&contacts[]=toto\&contacts[]=bidule\&groups[]=team\&groups[]=friends\&text=Texte%20du%20SMS%20à%20envoyer

#Requête POST
curl -X POST http://URLCIBLE/smsAPI/ -d 'email=admin@email.tld&password=p455w0rd&numbers=0612345678&contacts[]=toto&contacts[]=bidule&groups[]=team&groups[]=friends&text=Texte%20du%20SMS%20à%20envoyer'

Création d'un message à envoyer le 23/11/2020 à 17h42 au 0612345678

#Requête GET traditionnelle
curl http://URLCIBLE/smsAPI/?email=admin@email.tld\&password=p455w0rd\&numbers=0612345678\&date=2020-11-23%2017:42\&text=Texte%20du%20SMS%20à%20envoyer

#Requête POST
curl -X POST http://URLCIBLE/smsAPI/ -d 'email=admin@email.tld&password=p455w0rd&numbers=0612345678&date=2020-11-23%2017:42&text=Texte%20du%20SMS%20à%20envoyer'

Les retours

L'API retourne un résultat sous forme d'une chaîne JSON.
Le résultat (succès ou échec) de l'appel à l'API est retourné dans « error ».
Voici la liste des retours possibles :

Retour Description
{"error":0} Le SMS a été créé avec succès.
{"error":1} Les identifiants fournis sont incorrects
{"error":2} La création du SMS a échoué
{"error":3} Des arguments obligatoires sont manquants