Maintenir un fournisseur, ou apporter son API

1. Partir du modèleomni-provider-template porte un squelette par famille ; bin/init <famille> <service> remplit les noms, et sa suite est verte avant la première ligne.
2. Passer la suite de conformité de la familleChaque cœur livre sa suite en trait PHPUnit (<Cœur>\Testing). Le fournisseur y est monté sur des réponses enregistrées (MockHttpClient) : la suite ne touche jamais au réseau.
3. Prouver qu’il tourne hors de tout cadreTests/BareTest.php charge chaque classe avec les seules dépendances du paquet ; aucun cadre dans require, un client HTTP toujours accepté de l’extérieur.
4. Garder l’intégration continue au vertLes workflows du squelette appellent glitchr-studio/ci, épinglé à un commit : les tests à chaque push, une version avec ses notes, l’empreinte de son archive et une attestation de provenance à chaque étiquette.
5. Le proposerOuvrir un ticket « Fournisseur » : la famille, le service, sa politique d’usage, ce qui peut s’essayer en vrai. Le nom s’y arrête, puis le dépôt est créé sous glitchr-omnisense.

Qui maintient quoi

• Chaque dépôt de fournisseur vit dans l’organisation glitchr-omnisense, sous licence MIT, pour survivre à la disponibilité d’une seule personne.
• Chaque fournisseur nomme son mainteneur dans son README et dans CODEOWNERS ; l’entreprise qui tient l’API peut en être co-mainteneuse.
• Une modification est fusionnée après la relecture du mainteneur de la famille et une intégration continue verte qui passe la suite de conformité ; une modification du contrat d’une famille demande son mainteneur, jamais un fournisseur seul.
• La section « Verified, and not » du README dit ce qui a été essayé contre le vrai service, et quand ; le catalogue le montre tel qu’il est écrit.
• Un mainteneur qui se retire le dit dans un ticket ; le fournisseur passe en « mainteneur recherché » jusqu’à ce que quelqu’un le reprenne.

Proposer un fournisseur Lire « Écrire un fournisseur »

1. Relire son fournisseurLire le paquet qui appelle son API : les points d’accès, les erreurs qu’il traduit, les limites qu’il respecte. Un ticket ou une demande de fusion suffit.
2. Déclarer sa politique d’usage en donnéesChaque fournisseur porte sa politique en données : l’accès qu’il demande, une offre gratuite, l’usage commercial sur cette offre, le crédit à montrer (Policy : auth, free, commercial, attribution, credit, terms). Une application la lit avant d’appeler l’API, et montre le crédit comme il est demandé.
3. Le co-maintenirÊtre nommé dans son CODEOWNERS : les changements de l’API arrivent dans le paquet quand ils sortent, pas quand un utilisateur les remarque.
4. Être référencéL’API a sa carte au catalogue, avec sa politique et un lien vers ses conditions ; un fournisseur relu le dit.

policy:
  auth: key            # none | key | oauth | contract
  free: true
  commercial: yes      # yes | no | conditional | unclear
  attribution: required
  credit: 'Data from Example'
  terms: 'https://example.org/api-terms'

Relire ou déclarer son API Voir les fournisseurs publiés