Questa guida spiega come l'API Merchant gestisce il controllo delle versioni, le release e il ciclo di vita delle sue diverse versioni.
Schema di controllo delle versioni
L'API Merchant utilizza una strategia di controllo delle versioni a livello di API secondaria. Ciò significa che ogni API Merchant, ad esempio Products nell'API Merchant, avrà il proprio ciclo di vita della versione.
Formato e presentazione del controllo delle versioni
Versioni delle sub-API stabili: se una sub-API è in una versione stabile, tutti i suoi metodi sono in una versione stabile. Una versione stabile della sub-API è rappresentata come vX (ad esempio v1, v2). Queste sono versioni principali pronte per la produzione.
Versioni alpha delle sub-API: se una sub-API è in versione alpha, tutti i suoi metodi sono in versione alpha. Una versione alpha della sub-API è rappresentata come vXalpha (ad esempio, v1alpha, v2alpha). Contengono funzionalità sperimentali con accesso in anteprima destinate ai test e alla rapida iterazione. Le versioni alpha non offrono alcuna garanzia di stabilità, non hanno una durata definita e possono essere modificate o non essere più disponibili con un preavviso di 30 giorni.
Modifiche versione
- Incrementi della versione principale (ad esempio, da v1 a v2): indicano modifiche incompatibili con le versioni precedenti e che provocano un errore, che richiedono l'intervento dello sviluppatore. Solo le modifiche che provocano un errore delle sub-API stabili avranno un nuovo numero di versione. Ad esempio, da v1 a 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 in dettaglio nelle note di rilascio della versione principale. Le aggiunte non invasive a una sub-API verranno rilasciate nel canale alpha dell'ultima versione stabile o direttamente nell'ultima versione stabile.
Policy di ritiro
Periodicamente ritiriamo le versioni precedenti delle API secondarie di Merchant. Ci impegniamo a fornire 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 sub-API Products il 15 gennaio 2026, verrà disattivata non prima del 15 gennaio 2027. Dopo questa data, la versione precedente della sub-API non sarà più disponibile per l'utilizzo.
Versione e stato del ciclo di vita della sotto-API
La tabella seguente elenca le ultime versioni di ogni API secondaria dell'API Merchant:
| API secondaria | Versioni | Stato |
|---|---|---|
| Account | v1 v1alpha |
Attivo Attivo |
| Conversioni | v1 | Attivo |
| Origini dati | v1 | Attivo |
| Inventari | v1 | Attivo |
| Risoluzione dei problemi | v1 | Attivo |
| Partnership per i feed locali | v1 | Attivo |
| Notifiche | v1 | Attivo |
| Monitoraggio degli ordini | v1 | Attivo |
| Prodotti | v1 | Attivo |
| Product Studio | v1alpha | Attivo |
| Promozioni | v1 | Attivo |
| Quota | v1 | Attivo |
| Report | v1 | Attivo |
| Recensioni | v1alpha | Attivo |
Best practice
- Controlla regolarmente le note di rilascio e gli ultimi aggiornamenti per nuove versioni, aggiornamenti principali, miglioramenti e annunci relativi ai lanci e ai ritiri delle API secondarie.
- Se una sub-API ha due o più versioni stabili, ti consigliamo di utilizzare sempre l'ultima versione.
- Progetta la tua applicazione in modo che gestisca correttamente i vari errori delle sub-API, tra cui problemi di rete, limitazioni di frequenza e i nuovi codici di errore o messaggi che potrebbero essere introdotti con le versioni più recenti delle sub-API.
- Non aspettare che una versione di una sotto-API stia per essere ritirata per iniziare a pianificare l'upgrade. Inizia a valutare e testare le nuove versioni non appena sono disponibili.
- Per richieste di funzionalità o dubbi su una roadmap di una sub-API, contattaci per domande o feedback. Per informazioni su come contattare il team dell'API Merchant per ricevere assistenza tecnica, consulta Ricevi assistenza per l'API Merchant.