Differenze tra Apigee Edge e Apigee X

Immutabile al momento del deployment

È disponibile una soluzione simile, ma non identica. Consulta Utilizzare AppGroups per organizzare la proprietà delle app.

Pianificata

• Deployment asincroni
• Il recupero dello stato del deployment si basa sull'ultima tempo in cui il piano di runtime ha eseguito il "check-in" con il piano di gestione

• Supporto per i gruppi di ambienti
• Self-service tramite la UI e le API Apigee
• Maggiore flessibilità nella topologia di pubblicazione
• Un pod MP può gestire solo un ambiente

Per saperne di più, vedi Informazioni sugli ambienti e sui gruppi di ambienti.

Utilizza Cloud Run oppure Cloud Functions

Pianificata

L'utilizzo di [@.length-x] nelle espressioni JSONPath non è supportato in Apigee X. La specifica JSONPath indica che le espressioni dipendono dallo scripting sottostante lingua. length-x è un costrutto JavaScript, non Java, e [@.length-x] non è stato implementato nell'ambito della specifica. In Apigee X l'espressione [@.length-x] è sostituita dallo schema di indicizzazione ([-x]).

Per questo esempio:

{
    "books": [
      {
        "name": "A",
      },
      {
        "name": "B",
      }
    ]
}

L'input: $.books[@.length-1] restituisce {“name”: “B”} in Apigee Edge e restituisce [{“name”: “B”}] in Apigee X.

Collegamento a nord gestito come secret di Kubernetes

• Puoi creare KVM criptate con ambito di ambiente nella UI di Apigee. KVM sono sempre crittografati. Non puoi aggiungere, aggiornare o visualizzare le voci KVM nell'interfaccia utente.
• Utilizza l'attributo private. con tutte le variabili quando accedi a una KVM con il comando GET per nascondere le informazioni della KVM in una sessione di debug (Trace). Se l'attributo private. non è utilizzato, la KVM è ancora criptato; tuttavia, le informazioni KVM appariranno decriptate nella Trace di debug sessione e non verranno presentate eccezioni.
• Puoi gestire le voci KVM utilizzando API keyvaluemaps.entries o il . criterio KeyValueMapOperations.
• Puoi utilizzare i set di proprietà per alcuni degli stessi casi d'uso delle KVM. Consulta Utilizzo degli insiemi di proprietà.
• L'elemento <MapName> abilita il criterio KeyValueMapOperations per identificare la KVM da usare in modo dinamico in fase di runtime.

Per ulteriori informazioni sulla creazione di KVM nell'interfaccia utente, vedi Utilizzo delle mappe chiave-valore. Vedi anche Accesso configurazione per informazioni su come scegliere la giusta persistenza dei dati meccanismo di attenzione.

• I proxy API Node.js non sono supportati.
• Apigee consiglia di ospitare le applicazioni Node.js come container separati in Kubernetes (cluster stesso o diverso)

• Nuove norme:
  .
  • criterio AssertCondition: valuta un'istruzione condizionale in fase di runtime nel nei flussi di richiesta o risposta.
  • Criterio CORS: consente le chiamate JavaScript XMLHttpRequest (XHR) eseguite in un ambiente web per interagire con le risorse di domini non di origine.
  • Criterio Data Capture: sostituisce il criterio StatisticsCollector.
  • Criterio di callout esterno: invia le richieste gRPC al server gRPC per l'implementazione un comportamento personalizzato non supportato dai criteri di Apigee.
  • Criterio GraphQL: analizza i payload di GraphQL in variabili di flusso dei messaggi, verifica Richieste GraphQL in base a uno schema, o entrambi.
  • Criteri PubblicaMessaggi: pubblica le informazioni sul flusso del proxy API in un di Google Cloud Pub/Sub.
  • Revoca criterio OAuthv2: revoca per ID utente, ID app o entrambi.
  • Criterio Trace Capture: aggiunge ulteriori variabili alla traccia del runtime Apigee e i dati di Google Cloud.
• Criterio non supportato:
  .
  • Criterio StatisticsCollector (sostituito dal nuovo criterio Data Capture)
• Norme modificate:
  .
  • Criterio MessageLogging: non supporta il logging dei file

• Funzionalità gestita tramite il servizio IAM della console Google Cloud
• Sono disponibili alcuni ruoli predefiniti pronti all'uso
• Puoi creare ruoli personalizzati che possono includere altre autorizzazioni Google Cloud

Per ulteriori informazioni, vedi Utenti e ruoli.

Per Apigee hybrid:

• Il traffico in entrata viene implementato tramite Anthos Service Mesh.
• Il deployment delle chiavi e dei certificati viene eseguito direttamente in Kubernetes.

Per Apigee X:

• Ogni istanza espone un endpoint HTTPS tramite certificato autofirmato. La CA per puoi scaricare il certificato inviando una query all'organizzazione.