Compatibilità diretta

Cos'è la compatibilità diretta

La compatibilità diretta (forward compatibility) è la capacità del sistema di lavorare correttamente con clienti o dati più recenti rispetto a quelli inizialmente progettati. Semplice: il vecchio server non si rompe quando arriva un nuovo client; il vecchio consumatore non cade quando incontra un nuovo messaggio.

Dalla compatibilità inversa (quando il nuovo sistema supporta i clienti più vecchi), forward si distingue per la responsabilità di progettare protocolli e clienti in modo da «sopravvivere» alle future espansioni senza un upgrade totale dell'intero ecosistema.

Principi di base

1. Tolerant reader & tolerant writer

Reader ignora i campi/intestazioni sconosciuti e consente nuovi valori enum con fallback corretto.
Writer non invia nulla che il server non abbia chiaramente dichiarato come supportato (capabilities).

2. Capability negotiation

Condivisione esplicita di funzionalità (file/versioni/tipi multimediali) nella fase handshake. Il client adatta il proprio comportamento alla risposta del server.

3. Degrado in default

Le nuove funzionalità sono considerate opzionali: se il server/console non le supporta, lo script si conclude comunque con un minimo utile (MGC).

4. Nucleo stabile (MGC)

Il contratto minimo di garanzia è invariato; Le innovazioni si stanno espandendo.

5. Contratti di errore come parte del protocollo

I codici/cause prevedibili («Fic non supportato», «tipo di media sconosciuto») consentono al client di annullare automaticamente la modalità supportata.

6. Versioni senza sorprese

Linee maggiori separate; Le estensioni minori non richiedono l'aggiornamento del server/console.

Dove questo è particolarmente importante

API pubbliche con integrazioni a lunga vita (partner, SDK in applicazioni mobili).
Piattaforme di eventi con più notebook indipendenti.
Clienti mobili che si aggiornano più lentamente del backend.
Edge/IoT, dove parte del parco dispositivi è raramente richiesto.

Modelli di implementazione per stile

REST/HTTP

• «Accept »/mediatipi con parametri ('application/vnd. example. order+json; v=1; profile=risk`).
• «Prefer: include =...» per i blocchi opzionali.
• Titolo «X-Capabilities: risk _ score, item _ details _ v2».

• Invia una richiesta in formato base, estensioni solo se il server ha confermato la capabilità (tramite OPZIONI/desc/leed endpoint).
• Quando «415/406/501» viene automaticamente ripristinato al formato/metodo supportato.
• Risposta del server: impostazioni sconosciute - Ignora; Campi superflui - ammessi il formato di errore è stabile ('type/code/detail/trace _ id').

gRPC / Protobuf

Servizi stabili: nuovi metodi/campi - additivo; il vecchio server ignora tranquillamente i campi di query sconosciuti.
Feature discovery: il metodo «GetCapabilities ()» restituisce gli elenchi fich/limiti. Il client non chiama il metodo v2 se il server non lo dichiara.
Streaming - Fissa l'ordine del set minimo di messaggi. contrassegnare le nuove cornici con estensioni/tipi che il vecchio client ignora.

GraphQL

Forward-friendly - Nuovi campi/tipi vengono visualizzati sul server - i vecchi client semplicemente non li richiedono.
Le congetture sono proibite: il client deve mantenere lo schema (introspezione/codogeno) e non inviare direttive/variabili sconosciute.
Degrado: se il server non conosce la direttiva/feature custome, il client costruisce una query senza di essa.

Event-driven (Kafka/NATS/Pulsar, Avro/JSON/Proto)

CONNETTIVITÀ FORWARD DELLO SCHEMA NEL REGISTRO DI SISTEMA - I vecchi computer possono leggere i messaggi scritti dal nuovo schema.
Campi di default additivi: i nuovi produttori non rompono i vecchi consoomer.
Core vs Entriched: il kernel rimane lo stesso, le nuove informazioni vengono pubblicate in «.enriched» o come campi opzionali.

Pratiche di progettazione

1. Contratto di richiesta minima (MGC)

L'operazione deve avere una stretta cervicale che supporta tutti i server da anni.

2. Flag Fiech a livello di contratto

Descrivi i fili come funzionalità denominate «risk _ score», «pricing _ v2», «strong _ idempotency». Il cliente li accende chiaramente.

3. Codici di errore espliciti per «non supportato»

HTTP: `501 Not Implemented`, `415 Unsupported Media Type`, детальные `problem+json`.
gRPC: `UNIMPLEMENTED`/`FAILED_PRECONDITION`.
Events: percorso DLQ con'reason = unsupported _ feature '.

4. Non fare affidamento sull'ordine/elenco completo

Il client deve essere pronto ai nuovi valori enum, alla mancanza di nuovi campi e alle proprietà «aggiuntive».

5. Identificatori e formati stabili

Non cambiare il formato ID/chiavi di partizionamento all'interno della linea - questo rompe forward dal lato dei lettori.

6. Documentazione «leggibile»

Host descrittore: SDL. I clienti possono controllare il supporto del Fich.

Test di compatibilità forward

Schema-differf in modalità FORWARD/FULL: il nuovo schema valuta il vecchio utente/server.
Test del contratto del client: il nuovo client viene eseguito contro il vecchio server con i file attivati/disattivati.
Golden recests: una serie di richieste «nuove» vengono esaminate nel server «vecchio»; si prevede una degradazione senza errori critici.
Chaos/latency - Controllo timeout/retrai - il nuovo client deve sopravvivere correttamente alle peggiori SLA del vecchio server.
Canary: parte dei nuovi client lavora con la versione precedente del server - raccogliendo la telemetria degli errori/degrado.

Osservabilità e metriche operative

Percentuale di richieste/messaggi con file non supportate e relativi ritiri automatici.
Distribuzione per versione client (User-Agente/metadati/clims).
Errori DLQ con unsupported _ feature.
Tempo di degrado: p95/p99 per MGC contro risposta «estesa».

Modalità di compatibilità nel registro degli schemi

FORWARD: la nuova voce è compatibile con il vecchio lettore (sono necessari default, opzionalità).
FULL: и FORWARD, и BACKWARD; È utile per gli appalti pubblici.
Raccomandazione: per gli eventi - BACKWARD presso il produttore e FORWARD presso il consumer (tramite tolerant reader), API esterne - FULL.

Esempi

REST (capabilities + degrado)

1. Il client fa "GET/meta/capabilities" {"risk _ score": false, "price _ v2": true} ".
2. «POST/orders» invia i campi di base; «risk _ score» non lo richiede perché il server non lo sa fare.
3. Se invia accidentalmente "Prefere: include = risk _ score", il server risponde 200 senza il campo "risk _ score" (o'Preference-Applied: none ") - il client non cade.

gRPC (discovery)

«GetCapabilities ()» ha restituito la lista dei metodi/fich. Il client non chiama «CaptureV2» se non è presente; invece utilizza «Capture» e trasforma localmente i dati di input fino alla vista supportata.

Events (FORWARD nel registro)

Il produttore ha aggiunto il campo «risk _ score». Il vecchio consuntivo lo ignora; la sua logica utilizza solo i campi stabili del nucleo.

Antipattern

Client rigido: filtra la risposta nei campi whitelist e cade su proprietà sconosciute.
Files implicite: il client inizia a inviare una nuova opzione senza controllo di capabilities.
Cambiare i formati ID/chiavi all'interno della linea, i vecchi server/notebook smettono di comprendere le nuove richieste/messaggi.
Suggerimenti ricuciti sull'elenco completo enum (switch senza default).
Loging come controllo flusso: parsing delle righe di errore al posto dei codici contrattuali.

Assegno foglio di implementazione

• Definito da MGC; le nuove funzionalità sono contrassegnate come opzionali.
• Descritto e implementato da capability negotion (endpoint/metadati/handshake).
• I client ignorano campi sconosciuti e gestiscono correttamente i nuovi enum (fallback).
• I contratti di errore registrano «non supportato» prevedibilmente (HTTP/gRPC/Event).
• Il registro degli schemi è configurato su FORWARD/FULL per gli artefatti appropriati.
• Autostop: schema-differf (FORWARD), test di contratto client contro il vecchio server, canary.
• Metriche: versione client, rifiuto Fic, percentuale di degrado, p95 MGC.
• Documentazione/SDK pubblicano un elenco di file e esempi di degrado.

FAQ

In che modo forward è diverso dal backward in pratica?
Backward: il nuovo server non rompe i vecchi client. Forward: il vecchio server non si rompe con i nuovi client (o con i nuovi messaggi). Idealmente si raggiunge full.

È necessario introdurre sempre capabilities?
Se ti aspetti un'evoluzione attiva senza rilasci sincronizzati, sì. È più economico che mantenere decine di linee maggiori.

E la sicurezza?
I nuovi fili devono richiedere scopes/clims separati. Se il server non li supporta, il client non deve abbassare la sicurezza, ma deve rinunciare alla fitta.

È possibile «indovinare» il supporto del server?
Non è consigliabile. È meglio chiedere chiaramente (capabilities) o guardare mediatip/schema.

Totale

Compatibilità diretta è la disciplina di negoziare opportunità e degradare in modo sicuro. Il kernel stabile, la capability negotion, le estensioni additive e gli errori prevedibili consentono ai nuovi clienti e ai nuovi dati di convivere con i vecchi server e i consumatori - senza comunicazioni di massa o migrazioni notturne.