Introduzione agli anti-pattern

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Questa sezione riguarda gli antipattern comuni osservati nell'ambito dei proxy API di cui è stato eseguito il deployment sulla piattaforma Apigee Edge.

La buona notizia è che ciascuno di questi antipattern può essere chiaramente identificato e corretto con pratiche appropriate. Di conseguenza, le API implementate su Edge svolgerebbero lo scopo previsto e sarebbero più performanti.

Riepilogo degli anti-pattern

La tabella seguente elenca gli antipattern in questa sezione:

Categoria	Anti-pattern
Anti-pattern dei criteri	Emissione di token di aggiornamento senza richiamare il flusso di aggiornamento Utilizzare waitForComplete() nel codice JavaScript Impostare un periodo di scadenza lungo per i token OAuth Utilizzare quantificatori greedy nel criterio RegularExpressionProtection Memorizzare nella cache le risposte di errore Memorizzare nella cache dati di dimensioni superiori a 512 kB Registrare i dati sui server di terze parti utilizzando il criterio JavaScript Utilizzo di una versione di JSONPath non conforme Richiamare MessageLogging più volte in un proxy API Identificatori con cardinalità elevata nelle norme relative alle quote Configurare una quota non distribuita Riutilizzare un criterio Quota Utilizzare il criterio RaiseFault in condizioni inappropriate Accedere in modo errato a intestazioni HTTP multivalore in un proxy API Utilizzare callout di servizio per richiamare il servizio di backend in un proxy non di destinazione Utilizzo di norme OAuth V1, che sono ritirate. Consulta la sezione Ritiri.
Anti-pattern delle prestazioni	Mantenere il deployment dei proxy API NodeJS inutilizzati
Anti-pattern generici	Richiamare chiamate API di gestione da un proxy API Richiamare un proxy all'interno di un proxy utilizzando un codice personalizzato o come target Gestire le risorse Edge senza utilizzare la gestione del controllo del codice sorgente Definire più host virtuali con lo stesso alias host e numero di porta Bilanciamento del carico mediante un singolo server di destinazione con MaxFailures impostato su un valore diverso da zero Accedere al payload della richiesta/risposta quando lo streaming è attivato Definire più ProxyEndpoint in un proxy API
Anti-pattern di backend	Consentire un backend lento Disattivare le connessioni HTTP permanenti (keep-alive riutilizzabile)
Anti-pattern di Edge for Private Cloud	Aggiungere informazioni personalizzate allo schema di proprietà di Apigee nel database Postgres

Scarica l'ebook sugli anti-pattern

Oltre ai link riportati sopra, puoi anche scaricare gli antipattern in formato ebook:

• The Book of Apigee Edge Antipatterns v2.0 (PDF)

Che cos'è un antipattern?

Wikipedia definisce un antipattern software come:

format_quote

Nell'ingegneria del software, un anti-pattern è un pattern che può essere comunemente utilizzato, ma è inefficace e/o controproducente nella pratica.

format_quote

In parole semplici, un antipattern è qualcosa che il software consente all'utente di fare, ma che potrebbe avere un impatto negativo a livello funzionale, di manutenzione o di prestazioni.

Ad esempio, considera "Classe/oggetto Dio", che suona onnipotente.

Nel linguaggio orientato agli oggetti, una classe god è una classe che controlla troppe classi per una determinata applicazione.

Ad esempio, considera un'applicazione con il seguente albero di riferimenti:

Come illustrato nell'immagine, la classe god utilizza e fa riferimento a troppe classi.

Il framework su cui è stata sviluppata l'applicazione non impedisce la creazione di una classe di questo tipo, ma presenta molti svantaggi, i principali sono:

• Difficile da mantenere
• Single point of failure durante l'esecuzione dell'applicazione

Di conseguenza, è necessario evitare la creazione di una classe di questo tipo. Si tratta di un antipattern.

Pubblico di destinazione

Questa sezione è più utile agli sviluppatori di Apigee Edge man mano che avanzano nel ciclo di vita della progettazione e dello sviluppo di proxy API per i loro servizi. Idealmente, dovrebbe essere utilizzata come guida di riferimento durante il ciclo di sviluppo dell'API e durante la risoluzione dei problemi.