Ingénierie logicielle
Faire communiquer vos systèmes entre eux, de manière fiable
La plupart des travaux d'intégration échouent sur le chemin malheureux. La démo fonctionne, le cas heureux fonctionne, puis le fournisseur de paiement dépasse le délai d'attente au milieu d'une requête, ou l'API de comptabilité vous limite à la fin du mois, et personne ne sait si la commande a été créée deux fois ou pas du tout. Gérer cela correctement est le vrai travail.
Indicatif
Intégration à partir de £4 500 ; API complète à partir de £12 000
Prix fixe convenu par écrit avant le début de la réalisation.
Demander un devis+44 7488 265083Le problème que cela résout
Deux schémas causent la majorité des problèmes d'intégration. Appeler une API tierce de manière synchrone au sein d'une requête web, de sorte que leur journée lente devienne votre panne. Et l'absence d'idempotence, donc une nouvelle tentative crée une commande en double, une facture en double, ou un prélèvement en double — et le fait de régulariser cela manuellement coûte plus cher que de l'avoir correctement conçu dès le départ.
Ce que vous obtenez
Conçu avant d'être construit
Ressources, verbes, codes de statut, formes d'erreur, pagination et versionnage convenus à l'avance sous forme de spécification OpenAPI. Modifier une API publiée est coûteux ; modifier un document ne l'est pas.
Authentification adaptée au consommateur
OAuth 2.0 lorsque des tiers agissent au nom d'un utilisateur, clés signées pour les communications serveur à serveur, jetons à courte durée de vie avec rafraîchissement pour les clients mobiles. Choisi en fonction de qui appelle plutôt que par habitude.
Idempotence et nouvelles tentatives
Les opérations d'écriture acceptent une clé d'idempotence, de sorte qu'une requête répétée ne peut pas créer un second enregistrement. Les appels sortants utilisent une atténuation exponentielle avec un disjoncteur, de sorte qu'une dépendance défaillante se dégrade plutôt que de provoquer une cascade.
Webhooks pouvant être fiables
Charges utiles signées, protection contre les rejoués et journal de livraison avec redistribution manuelle. Du côté du récepteur, vérifier puis mettre en file d'attente — ne jamais traiter un webhook de manière synchrone au sein de la requête.
Limitation de débit et quotas
Limites par consommateur avec en-têtes clairs et codes 429, afin qu'un client ne puisse pas dégrader le service pour tous les autres. C'est ce qui rend une API sûre à donner à un partenaire.
Documentation qui reste fidèle
Générée à partir de la spécification et publiée avec des exemples réels de requêtes et de réponses, afin qu'elle ne dévie pas de l'implémentation comme le font toujours les documentations rédigées à la main.
Notre méthode de travail
Cartographier le flux
Quelles données circulent, dans quel sens, à quelle fréquence, et ce qui doit se passer lorsqu'une étape échoue. La question de l'échec est celle qui façonne la conception.
Spécifier
Document OpenAPI revu avec ceux qui consommeront l'API, avant que le code n'existe. Les consommateurs repèrent des problèmes de conception que les producteurs ne voient pas.
Construire selon un contrat
Implémentation plus tests de contrat, de sorte qu'un changement incompatible échoue dans le CI plutôt que dans l'intégration d'un partenaire.
Renforcer les interfaces
Délais d'attente, réessais, disjoncteurs, files d'attente de messages non distribués et journalisation structurée.
Environnement de test et mise en production
Un environnement bac à sable avec des identifiants de test pour permettre aux consommateurs de développer, puis une mise en production progressive.
Surveillance
Taux d'erreurs, latence et nombre d'échecs par intégration, avec alertes dès qu'une dépendance commence à dysfonctionner, et non après l'échec.
Ce à quoi vous devez vous attendre
- Une panne chez un tiers dégrade une seule fonctionnalité au lieu de l’ensemble du site
- Les relances ne peuvent pas créer de commandes, factures ou prélèvements en double
- Les partenaires s’intègrent à partir de la documentation sans solliciter votre équipe
- Les modifications disruptives sont détectées par des tests de contrat, et non par un partenaire
Créé avec
- Node.js
- TypeScript
- Laravel
- PHP
- Python
- FastAPI
- OpenAPI
- GraphQL
- REST
- PostgreSQL
- MySQL
- Redis
- RabbitMQ
- Stripe
- Xero
- QuickBooks
- Shopify
- Twilio
- SendGrid
Mainstream, well-supported technology — chosen so you can hire for it and so another team could take the project over.
Développement et intégration d'API — your questions
Y compris les questions relatives au coût, que la plupart des agences omettent sur leur site.
Une intégration bien délimitée — un fournisseur de paiement ou une synchronisation CRM — coûte généralement entre £4 500 et £9 000. Une API complète destinée à des consommateurs externes, avec authentification, limitation de débit, bac à sable et documentation, commence à £12 000. La variable principale est presque toujours le comportement du système tiers.
REST pour la plupart des cas, et GraphQL uniquement lorsque le client a vraiment besoin de composer ses propres requêtes sur des données liées — typiquement une application mobile cherchant à réduire les allers-retours. GraphQL ajoute une complexité réelle en termes de mise en cache, de limitation de débit et de contrôle des coûts de requête, donc il faut une raison valable au-delà d’une simple préférence.
Souvent, mais nous serons clairs sur les compromis. Les options sont une intégration au niveau de la base de données si nous y avons accès, un échange de fichiers planifié, ou en dernier recours le grattage d’écran — qui fonctionne mais se brise dès que l’autre partie modifie son code HTML. Nous facturons le grattage comme une maintenance continue plutôt qu’un projet ponctuel, car c’est ce qu’il est.
C’est prévu dès le départ. Les appels sortants passent par une file d’attente avec relances et un disjoncteur, donc une panne chez le prestataire entraîne un retard plutôt qu’une erreur ou une page 500. Tout ce qui est irrécupérable est dirigé vers une file de messages morts avec alerte, pour éviter toute perte silencieuse.
Oui, générée à partir de la spécification OpenAPI pour éviter qu’elle ne devienne obsolète, publiée avec des exemples fonctionnels et un bac à sable pour tester. Une documentation d’API rédigée manuellement devient obsolète en deux versions, c’est pourquoi nous ne procédons pas ainsi.
Versionnée dans le chemin de l’URL, avec une politique de dépréciation écrite — les modifications non disruptives sont ajoutées à la version actuelle, les modifications disruptives donnent lieu à une nouvelle version, et l’ancienne reste disponible pendant une période convenue. Les consommateurs planifient en conséquence au lieu de le découvrir après coup.
Services associés
La plupart des projets touchent à plus d’un de ces services.
Logiciels sur mesure
Systèmes sur mesure qui remplacent les tableurs, les transferts manuels et les outils standard que votre entreprise a dépassés.
Lire la suiteDéveloppement de produits SaaS
Multi-locataires, facturation, rôles et intégration conçus une fois pour que les cent prochains clients ne nécessitent pas de refonte.
Lire la suiteDéveloppement web
Sites web et applications web sur mesure conçus pour la rapidité, la visibilité dans les moteurs de recherche et une maintenabilité à long terme.
Lire la suiteParlez à quelqu'un qui l'a déjà développé
A short call is usually enough to tell you whether this is the right service for your situation — including when it is not.