Questa guida spiega come l'API Merchant gestisce il versionamento, le release e il ciclo di vita delle sue diverse versioni.
Schema di controllo delle versioni
L'API Merchant utilizza una strategia di gestione delle versioni a livello di API secondarie. Ciò significa che i singoli componenti o servizi all'interno dell'API Merchant avranno il proprio ciclo di vita della versione.
Formato e presentazione del controllo delle versioni
Versioni delle sotto-API stabili: se una sotto-API è in versione stabile, tutti i suoi metodi sono in versione stabile. La versione della sottoAPI stabile è rappresentata come vX (ad esempio v1, v2). Si tratta di versioni principali pronte per la produzione.
Versioni alpha delle sottoAPI: se una sottoAPI è in versione alpha, tutti i suoi metodi sono in versione alpha. La versione della sottoAPI alpha è rappresentata come vXalpha (ad es. v1alpha, v2alpha). Si tratta di versioni sperimentali con accesso in anteprima destinate a test e iterazioni rapide. Le versioni alpha non sono garantite per quanto riguarda la stabilità e non hanno un ciclo di vita garantito. Le versioni alpha possono essere modificate o interrotte con un preavviso di 30 giorni.
Modifiche versione
Incrementi di versioni principali (ad esempio dalla versione 1 alla versione 2): indicano modifiche incompatibili con le versioni precedenti e che provocano errori, che richiedono l'intervento dello sviluppatore. Solo le modifiche che comportano un interruzione delle API secondarie stabili avranno un nuovo numero di versione. Ad esempio, dalla versione v1 alla versione v2.
Modifiche minori:le aggiunte o le correzioni compatibili con le versioni precedenti vengono presentate come modifiche alla versione principale esistente. Queste modifiche verranno descritte nel dettaglio nelle note di rilascio della versione principale. Le aggiunte non incompatibili a una sotto-API verranno rilasciate nel canale alpha dell'ultima versione stabile o direttamente nell'ultima versione stabile.
Tramonti
Periodicamente ritiriamo le versioni precedenti delle API secondarie Merchant. Ci impegniamo a garantire un periodo di ritiro di 12 mesi per le versioni principali stabili (vX), a partire dall'annuncio ufficiale del ritiro.
Ad esempio, se ritiriamo la versione 1 della sottoAPI Products il 15 gennaio 2026, il ritiro verrà eseguito non prima del 15 gennaio 2027. Dopo questa data, la versione precedente della sottoAPI non sarà più disponibile.
Versione dell'API secondaria e stato del ciclo di vita
La tabella seguente elenca le versioni più recenti di ogni sottoAPI dell'API Merchant:
| API secondarie | Versioni alpha | Versioni beta | Stato |
|---|---|---|---|
| Account | Non disponibile | v1 beta | La versione beta 1 è attiva |
| Prodotti | Non disponibile | v1 beta | La versione beta 1 è attiva |
| Input dei prodotti | Non disponibile | v1 beta | La versione beta 1 è attiva |
| Inventari locali | Non disponibile | v1 beta | La versione beta 1 è attiva |
| Inventari regionali | Non disponibile | v1 beta | La versione beta 1 è attiva |
| Origini dati | Non disponibile | v1 beta | La versione beta 1 è attiva |
| Promozioni | Non disponibile | v1 beta | La versione beta 1 è attiva |
| Report | Non disponibile | v1 beta | La versione beta 1 è attiva |
| Conversioni | Non disponibile | v1 beta | La versione beta 1 è attiva |
| Notifiche | Non disponibile | v1 beta | La versione beta 1 è attiva |
| Recensioni | Non disponibile | v1 beta | La versione beta 1 è attiva |
| Impostazioni di spedizione | Non disponibile | v1 beta | La versione beta 1 è attiva |
| Product Studio | v1 alpha | Non disponibile | La versione alpha v1 è attiva |
Best practice
- Controlla regolarmente le note di rilascio e gli aggiornamenti più recenti per trovare nuove versioni, aggiornamenti importanti, miglioramenti e annunci relativi al lancio e al ritiro delle API secondarie.
- Se una sottoAPI ha due o più versioni stabili, ti consigliamo di utilizzare sempre la versione più recente.
- Progetta l'applicazione in modo che gestisca in modo corretto vari errori delle API secondarie, inclusi problemi di rete, limiti di frequenza e nuovi codici o messaggi di errore che potrebbero essere introdotti con le versioni più recenti delle API secondarie.
- Non aspettare che una versione dell'API secondaria stia per essere ritirata per iniziare a pianificare il tuo upgrade. Inizia a valutare e testare le nuove versioni non appena diventano disponibili.
- Per richieste di funzionalità o dubbi sulla roadmap di una sottoAPI, contattaci con domande o feedback. Per informazioni su come contattare il team dell'API Merchant per ricevere assistenza tecnica, consulta Ricevere assistenza per l'API Merchant.