Au niveau le plus basique, une API est un mécanisme permettant à une application ou à un service d'accéder à une autre application ou service. L'application ou le service effectuant l'accès est appelé le client et l'application ou le service contenant la ressource est appelé le serveur.

Certaines API, comme SOAP ou XML-RPC, imposent un cadre strict aux développeurs. Mais les API REST peuvent être développées à l'aide de presque tous les langages de programmation et elles prennent en charge une grande variété de données. La seule exigence est qu'elles respectent les six principes de conception REST suivants, également appelés contraintes architecturales :

1. interface uniforme. Toutes les API pour la même ressource doivent rechercher la même chose, quelle que soit l'origine de la requête. L'API REST doit s'assurer que les mêmes données, notamment le nom ou l'adresse de courrier électronique d'un utilisateur, appartiennent à un seul URI (Uniform Resource Identifier). Les ressources ne doivent pas être trop volumineuses mais doivent contenir tous les élément d'informations dont le client peut avoir besoin.
2. Dissociation client-serveur. Dans la conception d'API REST, les applications clients et serveurs doivent être totalement indépendantes les unes des autres. Les seules informations que l'application client doit connaître sont l' URI de la ressource demandée ; elle ne peut pas interagir avec l'application serveur d'une autre manière. De même, une application serveur ne doit pas modifier l'application client autrement qu'en transférant les données demandées via le protocole HTTP.
3. Absence d'état. Les API REST n'ont pas d'état, ce qui signifie que chaque requête doit inclure toutes les informations nécessaires à son traitement. En d'autre termes, les API REST ne nécessitent aucune session côté serveur. Les applications serveur ne sont pas autorisées à stocker les données concernant une demande du client.
4. Capacité de mise en cache. Lorsque cela est possible, les ressources doivent pouvoir être mises en cache côté client ou serveur. Les réponses du serveur doivent également contenir des informations sur l'autorisation de la mise en cache pour la ressource fournie. L'objectif est d'améliorer les performances côté client, tout en augmentant l'extensibilité côté serveur.
5. Architecture système en couches. Dans les API REST, les appels et les réponses passent par différentes couches. Comme règle empirique, ne partez pas du principe que les applications client et serveur se connectent directement les unes avec les autres. Il peut y avoir un certain nombre d'intermédiaires différents dans la boucle de communication. Les API REST doivent être conçues afin que ni le client ni le serveur ne puisse dire s'il communique avec l'application finale ou un intermédiaire.
6. Code à la demande (facultatif). Les API REST envoient généralement des ressources statiques, mais dans certains cas, les réponses peuvent également contenir du code exécutable (tels que des applets Java). Dans ces cas, le code ne doit s'exécuter qu'à la demande.

Les API REST communiquent via des requêtes HTTP pour effectuer des fonctions de base de données standard telles que la création, la lecture et la suppression d'enregistrements (également appelés CRUD) dans une ressource. Par exemple, une API REST utiliserait une requête GET pour récupérer un enregistrement, un requête POST pour en créer un, une requête PUT pour mettre à jour un enregistrement et une requête DELETE pour en supprimer un. Toutes les méthodes HTTP peuvent être utilisées dans des appels d'API. Une API REST conçue correctement est semblable à un site Web s'exécutant dans un navigateur Web avec une fonctionnalité HTTP intégrée.

L'état d'une ressource à un instant précis ou une date et heure spécifiques est connu sous le nom de représentation de ressource. Ces informations peuvent être fournies à un client dans pratiquement tous les formats, y compris JavaScript Object Notation (JSON), HTML, XLT, Python, PHP ou en texte normal. JSON est populaire car il est lisible par les humains et les machines et ne dépend pas du langage de programmation.

Les en-têtes et les paramètres de requête sont également importants dans les appels d'API REST car ils incluent des informations d'identifiant importantes telles que les métadonnées, les autorisations, les URI, la mise en cache, les cookies, etc. Les en-têtes de requête et de réponses, ainsi que les codes d'état HTTP conventionnels, sont utilisés dans les API REST bien conçues.

Bien que la flexibilité soit le grand avantage de la conception des API REST, cette même flexibilité facilite la conception d'une API endommagée ou à faibles performances. Pour cette raison, les développeurs professionnels partagent les meilleures pratiques dans les spécifications d'API REST.

La OpenAPI Specification (OAS) établit une interface pour décrire une API d'une manière permettant à tout développeur ou application de la découvrir et de comprendre totalement ses paramètres et fonctionnalités : les points de terminaison disponibles, les opérations autorisées sur chaque point de terminaison, les paramètres opérationnels, les méthodes d'authentification et d'autres informations. La version la plus récent récente, OAS3  (le lien réside en dehors du site ibm.com), comprend des outils, tels que OpenAPI Generator, pour générer des morceaux clients et serveur d'API dans différents langages de programmation.

La sécurisation d'une API REST commence donc par les meilleures pratiques du secteur industriel, notamment l'utilisation d'algorithmes de réadressage calculé et du HTTPS pour sécuriser la transmission des données. Une structure d'autorisation telle que OAuth 2.0  (le lien réside en dehors du site ibm.com) peut aider à limiter les privilèges des applications tiers. A l'aide d'un horodatage dans l'en-tête HTTP, une API peut également rejeter toute demande qui arrive après un certain temps. La validation des paramètres et les jetons Web JSON sont d'autres manières de s'assurer que seuls les clients autorisés accèdent à l'API.