API
Un OpenAPI 3.1 suffit : Flexway sert exactement ce qui y est déclaré, valide les requêtes contre le schéma et relaie vers vos services, en REST, gRPC, SSE ou WebSocket.
12 livrées sur les 13 présentées · depuis v0.1.0
Ce que vous attendez de ce domaine
Problème 1
La passerelle et le contrat divergent ; une route que plus personne ne connaît répond encore.
Réponse de Flexway : Seul ce que le contrat déclare est servi : une route non déclarée répond 404 en problem+json.
Problème 2
Une faute de frappe se découvre au déploiement, sous le trafic.
Réponse de Flexway : flexway validate refuse la configuration hors ligne, en CI ; une configuration invalide ne remplace jamais celle qui tourne.
Problème 3
Réécrire des centaines de routes d'une passerelle existante bloque tout changement.
Réponse de Flexway : La reprise de la configuration d'une passerelle existante produit la configuration et un rapport de couverture.
Chaque étape est une décision lisible dans la trace et dans la console.
API - Schéma du domaine : qui appelle, les étapes de décision, ce qui est appelé, et le cas de refus.
non déclarée : 404
Les applications qui appellent vos API : chaque requête passe par Flexway, qui vérifie le contrat et l'identité avant d'atteindre vos systèmes.
Trajets qui passent ici
Les navigateurs : appels REST et flux temps réel (SSE, WebSocket), relayés par Flexway sans mise en tampon.
Trajets qui passent ici
Les entreprises partenaires qui consomment vos API : identifiées par certificat client ou clé d'API, sous un quota par tenant.
Trajets qui passent ici
Flexway ne sert que ce que votre contrat OpenAPI, AsyncAPI ou Protobuf déclare ; le reste reçoit 404 sans atteindre vos services.
Trajets qui passent ici
Flexway vérifie qui appelle (jeton OIDC, clé d'API ou certificat client) et lit le tenant dans l'identité ; sans identité valide : 401.
Trajets qui passent ici
Les paramètres et le corps sont validés contre le schéma du contrat ; une requête non conforme reçoit 422 sans atteindre l'amont.
Trajets qui passent ici
Les politiques de la route : schéma du contrat, transformations, cache isolé par tenant, appel à un service de décision qui peut refuser.
Trajets qui passent ici
Flexway relaie vers l'amont sans tampon, sous un délai borné et un coupe-circuit ; chaque décision laisse une trace OpenTelemetry.
Trajets qui passent ici
Vos services HTTP : Flexway leur relaie les opérations déclarées, en HTTP/1.1 ou HTTP/2.
Trajets qui passent ici
Vos services gRPC : servis en gRPC, en gRPC-Web et en REST traduit par descripteurs Protobuf.
Trajets qui passent ici
Les flux SSE et WebSocket de vos services, relayés par Flexway sans mise en tampon.
Trajets qui passent ici
L'essentiel de chaque sujet, avec son statut dans la version publiée ; dépliez une carte pour le texte complet.
Flexway sert exactement les opérations du contrat OpenAPI : une route non déclarée répond 404, une opération sans amont empêche le démarrage.
Flexway charge un contrat OpenAPI 3.1 et en déduit l'ensemble des routes servies : exactement les opérations déclarées, ni plus ni moins. Une route absente du contrat répond 404 par construction, sans règle à écrire pour la fermer. Une opération déclarée sans amont empêche le démarrage : la passerelle refuse de servir une configuration partielle.
Le fichier flexway.yaml décrit comment servir - hôtes, amonts, émetteurs, politiques - et ne liste aucune opération. Ce qui est propre à une opération vit dans le contrat, en extensions relues avec elle par l'équipe qui la change : x-flexway-upstream, x-flexway-timeout, x-flexway-rate-class, x-flexway-cache, x-flexway-tool. Un hôte peut servir ses propres contrats (hosts.<hôte>.contracts) ; la même route deux fois sur un hôte, un operationId présent dans deux contrats ou une opération relayée vers deux amonts sont refusés au chargement.
Le décodage est strict : une clé inconnue est refusée, jamais ignorée, et tous les problèmes sont rapportés d'un coup. En reprenant une API existante, le 404 des opérations non déclarées révèle souvent des routes que l'ancienne passerelle exposait sans que le contrat les mentionne.
flexway validate vérifie la configuration hors ligne, en CI, et le rechargement à chaud ne remplace jamais la configuration en service par une invalide.
flexway validate vérifie, sans grappe ni réseau, que le fichier respecte son schéma, que les contrats se chargent, que chaque opération a un amont et qu'aucun amont n'est orphelin. Il sort en code non nul sur erreur, ce qui en fait une étape de CI, et imprime config_digest : l'empreinte sémantique de ce qu'il a chargé, identique quel que soit le chemin de montage. C'est la valeur qu'une CI peut attendre de voir servie après une fusion.
Le rechargement passe par un instantané immuable : l'empreinte du contenu est relue toutes les server.reload.interval (5 s par défaut) et sur SIGHUP. Cent rechargements sous charge n'ont perdu aucune requête, flux en cours compris, et les amonts et émetteurs inchangés sont réutilisés. Une configuration invalide ne remplace jamais celle qui tourne : le refus est journalisé une fois par version, compté (flexway.config.reloads) et visible dans last_reload de /config.
Les secrets ne s'écrivent que par référence, ${VAR} ou file:/chemin ; une valeur en clair sous une clé de secret refuse le chargement. Quelques réglages ne se rechargent pas (server.shutdown, observability, server.reload, server.in_flight, server.cache) : les modifier refuse le rechargement en bloc, avec le nom de la clé.
L'import ponctuel et hors ligne de la configuration d'une passerelle existante produit un flexway.yaml validé et un rapport de ce qui est repris ou sans équivalent.
La reprise de la configuration d'une passerelle existante est un import ponctuel et hors ligne, jamais une lecture au démarrage. Chaque endpoint est rapproché d'une opération du contrat par méthode et gabarit de chemin ; un endpoint absent du contrat est listé, jamais inventé. Le flexway.yaml produit passe par le chargeur réel avant d'être écrit : ce qui sort de l'import démarre.
La sortie, dans un dossier vide, comprend la configuration, le contrat annoté avec le même correctif en JSON Patch (RFC 6902), et un rapport de couverture qui classe chaque élément : repris, repris autrement, sans équivalent. Les amonts, délais, limites de débit et coupe-circuits trouvent leur place dans upstreams, x-flexway-timeout et les politiques ; un contrat moins strict que l'ancienne configuration est signalé, jamais modifié en silence. Les scripts embarqués et greffons natifs n'ont pas d'équivalent : aucun code tiers ne tourne dans le processus.
Flux SSE, WebSocket, gRPC et gRPC-Web sont relayés de bout en bout, et un amont gRPC devient appelable en REST depuis ses annotations google.api.http.
Les réponses SSE et les corps fragmentés sont relayés sans retenue : chaque fragment part dès qu'il arrive. Un flux n'est gouverné que par le délai d'inactivité entre deux octets (server.timeouts.read), jamais par le délai total de l'échange. Le WebSocket est relayé après les contrôles d'identité et de débit à l'ouverture, et la connexion survit au budget total. À l'arrêt, /readyz passe au rouge puis les flux en cours sont drainés dans une borne déclarée (server.shutdown.drain).
Un amont gRPC décrit par ses descripteurs Protobuf (contracts.protobuf) devient appelable en REST : la correspondance vient des annotations google.api.http, la réponse revient en JSON canonique proto3, et un flux serveur devient un text/event-stream, un message par évènement. gRPC et gRPC-Web sont aussi servis de bout en bout, en h2c ou en TLS sur l'écouteur de trafic, sans second port. Une erreur de la surface gRPC est un google.rpc.Status dont ErrorInfo.reason porte le code du problème.
Les correspondances que la traduction ne sait pas tenir (variable sur plusieurs segments, segment joker, verbe, flux client ou bidirectionnel en REST) sont refusées au chargement plutôt que servies approximativement. HTTP/3 côté appelant est à venir.
L'exemple rest-minimal, tel qu'il est livré avec Flexway v1.6.3.
# The smallest useful configuration: one contract, one upstream. Every operation of the contract is
# served and relayed there; nothing else is.
version: 1
contracts:
openapi: ./openapi.yaml
upstreams:
default:
url: http://orders.internal:8080openapi: 3.1.0
info:
title: Orders
version: "1.0.0"
# The team that answers for every operation of this contract - the console's catalogue shows it
#; an operation may name its own.
x-flexway-owner: { team: orders-team, contact: "#orders" }
paths:
/orders:
get:
operationId: listOrders
parameters:
- { name: status, in: query, schema: { type: string, enum: [open, closed] } }
responses: { "200": { description: The orders } }
post:
operationId: createOrder
requestBody:
required: true
content:
application/json:
schema:
type: object
required: [sku, quantity]
properties:
sku: { type: string }
quantity: { type: integer, minimum: 1 }
responses: { "201": { description: Created } }
/orders/{id}:
get:
operationId: getOrder
parameters: [ { name: id, in: path, required: true, schema: { type: string } } ]
responses: { "200": { description: One order } }Ce qui est livré dans la version publiée v1.6.3, et ce qui vient ; une fonctionnalité n'est jamais présentée comme livrée avant sa version.
| Fonctionnalité | Statut |
|---|---|
| Un contrat OpenAPI 3.1 chargé ; ce qui est servi en est déduit | Livré · v0.1.0 |
| flexway validate hors ligne, sortie exploitable en CI | Livré · v0.1.0 |
| Rechargement à chaud par instantané immuable, sans requête perdue | Livré · v0.1.0 |
| Reprise de la configuration d'une passerelle existante, avec rapport de couverture | Livré · v1.1.0 |
| Flux relayés sans retenue : SSE et corps fragmentés | Livré · v0.1.0 |
| WebSocket relayé | Livré · v0.1.0 |
| Traduction REST vers gRPC par descripteurs Protobuf | Livré · v0.2.0 |
| gRPC et gRPC-Web de bout en bout | Livré · v0.2.0 |
| HTTP/3 côté appelant | Prévu |
| Chaîne de politiques effective par route | Livré · v0.1.0 |
| Une configuration invalide ne remplace jamais celle en cours | Livré · v0.1.0 |
| Proposition déclarative : un diff, jamais une mutation | Livré · v1.2.0 |
| Ouverture d'une pull request depuis la proposition | Livré · v1.2.0 |
Les autres attentes de ce domaine
Flexwiz est une jeune entreprise : vous parlez directement avec la personne qui la fonde. Dites-nous ce que vous voulez faire passer par Flexway. Nous parlons de votre infrastructure et de vos exigences de souveraineté numérique.
La prise de rendez-vous en ligne arrive bientôt ; d'ici là, un e-mail suffit.