Qual è il vantaggio di versioning un API REST per data come fa Twilio?

Question

Fondamentalmente, penso che sia una buona idea per la versione tuo REST API. Questo è buon senso. Di solito si incontrano due approcci su come fare questo:

• entrambi i casi, si dispone di un identificatore di versione nella URL, ad esempio, /api/v1/foo/bar
• o, si utilizza un colpo di testa, come ad esempio Accept: vnd.myco+v1.

Fin qui, tutto bene. Questo è ciò che almost all big companies do. Entrambi gli approcci hanno i loro pro e contro, e molte di queste cose sono discusse here.

Ora ho visto un approccio completamente diverso, a Twilio, come descritto here. Utilizzano una data:

In fase di compilazione, lo sviluppatore include il timestamp dell'applicazione quando il codice è stato compilato. Quel timestamp va in tutte le richieste HTTP.

Quando la richiesta arriva in Twilio, lo fanno uno sguardo in su. Sulla base del timestamp identificano l'API che era valida quando questo codice è stato creato e si instrada di conseguenza.

È un approccio molto intelligente e interessante, anche se penso che sia un po 'complesso. Può essere fonte di confusione capire se il timestamp è il momento della compilazione o il timestamp quando l'API è stata rilasciata, per esempio.

Ora, mentre in qualche modo trovo questo abbastanza intelligente, mi chiedo quali siano i reali vantaggi di questo approccio. Naturalmente, questo significa che hai solo per documentare una versione del vostro API (quello attuale), ma d'altra parte rende la tracciabilità di ciò che è cambiato più difficile.

Qualcuno sa quali sono i vantaggi di questo approccio, quindi perché Twilio ha deciso di farlo?

Si prega di notare che sono consapevole che questa domanda sembra come se le risposte fossero principalmente basate sull'opinione pubblica, ma immagino che Twilio avesse una buona ragione tecnica per farlo. Quindi, per favore, non chiudere questa domanda come prima cosa basata sull'opinione, come spero che la risposta non lo sia.

Answer 1

Interessante domanda, +1, ma da quello che vedo hanno solo due versioni: 2008-08-01 e 2010-04-01. Quindi dal mio punto di vista questo è solo un altro modo di fare lo spelling v1 e v2 quindi non penso ci fosse un motivo tecnico, solo una preferenza.

Questo è tutto quello che potevo trovare sul loro decisione: https://news.ycombinator.com/item?id=2857407

EDIT: assicuratevi di leggere i commenti qui sotto in cui @kelnos e @andes menzionano un vantaggio di utilizzare un simile approccio alla versione API.

Answer 2

C'è un'altra cosa Posso pensare che ciò rende questo un approccio interessante se sei lo sviluppatore di tali API.

Hai 20 metodi e devi introdurre una modifica in 1 di questi.

Utilizzando semver (v1, v2, v3, ecc) è necessario un api v2. Ora tutti i 20 metodi devono rispondere a v2, ma in realtà questi metodi non sono affatto cambiati, non sono nuovi.

Utilizzando le date, è possibile mantenere i metodi invariati così come sono, e quando arriva la richiesta, è sufficiente scegliere la migliore corrispondenza.

Non so come è stato implementato, qualsiasi informazione in merito sarà davvero gradita.