Il primo modello REST è iniziato con la tesi di dottorato di Rob Fielding nel 2000. La tecnologia alla base della riscrittura degli URL esisteva fin dall'inizio - in effetti, si potrebbe dire che ogni server Web tradizionale è un'applicazione RESTFul che offre l'astrazione del file system.
Ma quello che probabilmente stai chiedendo è la popolarità - quando REST è diventato popolare per casi d'uso diversi dalla navigazione nei file system?
Parliamo invece di PERCHÉ REST è diventato popolare. Sento che la risposta deriva davvero da attriti in competizione.
Prima di tutto: prendiamo il termine "URL amichevoli". Gli ingegneri hanno sempre utilizzato url ottimizzati per il tipo di sviluppo più popolare al momento. Nel tuo esempio, blog.php?action=edit&id=1234 è molto amichevole - se stai lavorando in un singolo editor su un singolo file, ospitato da un motore che converte un file system in un server delle applicazioni. Sai che ci sarà un file chiamato blog.php e che ospiterà il codice che gestirà l'azione di modifica. Non importava che l'URL non fosse amichevole per gli utenti, poiché ci si aspettava che usassero il contenuto reso per attraversare l'applicazione, non l'URL.
Quando il Web è nato, l'hardware del server era costoso e la maggior parte delle applicazioni Web erano molto piccole rispetto alla capacità del server. Generalmente un server viene impostato per servire qualsiasi contenuto trovato in una directory (con regole per l'esecuzione di script con estensioni note), relativamente a un URL. Pertanto potresti avere http://example.com/ di contenuti pubblicati in /var/opt/wwwroot/example . Come sviluppatore, ti verrà assegnata una directory in cui lavorare; se volessi aggiungere alcune funzionalità al tuo programma, dovresti creare, acquistare o scaricare uno script e incollarlo in una directory (sapendo che sarebbe servito rispetto a quella directory. L'integrazione implicava la marcatura dello script per apparire come vuoi.
I seguenti fattori hanno contribuito a cambiare la definizione di "amichevole" da "amichevole per gli script di debug" a "amichevole per gli integratori:"
- I server sono diventati molto meno costosi; le domande sono diventate più complicate. Piuttosto che un server che esegue molte applicazioni, è diventato comune eseguire una singola applicazione su molti server.
- La maggior parte degli sviluppatori può eseguire i propri server dedicati, anziché condividere con altre organizzazioni / team; improvvisamente il collegamento tra URL e posizione su disco è diventato molto meno importante per il debug.
- Le aziende hanno iniziato a offrire agli sviluppatori versioni self-service e ospitate di applicazioni che prima erano vendute come script da servire (SaaS). All'improvviso, l'integrazione ha richiesto ALTRI PERSONE che guardavano i tuoi URL, persone a cui non importava che la tua applicazione fosse scritta in PHP, ma che gli URL richiedevano molto rumore non correlato.
- I "livelli aziendali" delle applicazioni si sono spostati dai protocolli binari proprietari a HTTP; questo è stato considerato utile per la cartolarizzazione e la semplificazione della rete. All'improvviso gli sviluppatori di "backend" avevano bisogno di un modo per integrarsi con i propri pari tramite URL. Ciò comportava alcuni passi falsi (come SOAP), URL che non riguardavano la posizione dei file ma erano ancora più dettagli dei sistemi di back-end rispetto ai dettagli degli integratori.
- Gli ingegneri che sentivano il dolore delle API difficili da integrare, sia interne che esterne, hanno scoperto il modello REST e sembrava legittimo. Ma stavano usando framework web ottimizzati per gli URL in cui la maggior parte delle informazioni è stata trasferita tramite intestazioni, parametri url e messaggi di forma. Per passare a un modello REST significava regole di riscrittura complicate e analisi degli URL homebrewed.
- Intorno al 2007, entra in Sinatra e altri - framework web che sfruttano l'hardware del server poco costoso per costruire un server web destinato a una singola applicazione, uno che integra il codice e l'instradamento degli URL in un'unica astrazione e crea i parametri di estrazione da un URL a preoccupazione del primo ordine. Poiché questi framework non erano progettati per creare app MVC HTML destinate ai browser, avevano meno parti mobili. Costruire un servizio Web indipendentemente dall'URL è più basso di attrito.
Tutti questi fattori: riduzione del costo del server, proprietà dei server da parte degli sviluppatori, http come trasporto per l'integrazione, urgenza per un'integrazione semplificata e nuovi framework che hanno reso l'integrazione tramite REST più semplice di una pagina Web - lentamente evoluto RESTful integrazione da una tesi di dottorato allo stile di integrazione più avanzato sia per lo sviluppo web pubblico che per lo sviluppo aziendale.