Come chiamare un'API HTTP che non è RESTful? [chiuso]

Come chiameresti un'API basata su HTTP, che utilizza l'URI per nominare risorse e verbi HTTP (PUT, POST, DELETE, GET ...) per manipolare tali risorse?

Secondo le lamentele di Roy Fielding non è REST, perché non esiste un ipermediale.

Internamente, nel mio team, tutti lo chiamano "API REST". Lo chiamo "REST-like" ma non è descrittivo e il suo significato è confuso. Sono piuttosto confuso al riguardo, dal momento che esiste un grande disaccordo su REST. Non voglio prendere parte alle guerre di fiamma, ma uso solo termini corretti.

Chiamalo un'API HTTP .

È conforme agli standard HTTP e non ha nient'altro a strati (ad esempio SOAP).

Gli standard HTTP definiscono risorse, verbi, intestazioni, negoziazione dei contenuti, ecc.

REST (REpresentational State Transfer) è un'architettura con requisiti che risultano compatibili con gli standard HTTP esistenti, ma HTTP funziona da solo.

Nella mia esperienza, il 90% di "API HTTP REST" dovrebbe definirsi "solo" un'API HTTP.

Non vergognarti di lasciare l'etichetta REST. Come per i microservizi e i database non relazionali, non è necessario disporre di un'API RESTful per essere interessanti. Roy ha deciso di creare l'architettura di applicazione di rete più longeva, la più retrocompatibile possibile. Ha fatto un buon lavoro. Ma non tutto ha bisogno di oltre 40 anni di compatibilità.

Richardson Maturity Models va così

0. POST ovunque. Un singolo endpoint. (SAPONE)
1. POST ovunque. Endpoint multipli. (risorse)
2. VERBI HTTP. Endpoint multipli.
3. Come 2 e restituisce collegamenti alle risorse. (Riposante)

Quindi, secondo il modello, lo definirei un servizio web conforme al livello 2 di Richardson o qualcosa del genere.

http://martinfowler.com/articles/richardsonMaturityModel.html

Hypermedia non è mai diventato molto popolare con le API simili a REST - al punto che quando un'API implementa effettivamente la navigazione ipermediale, il termine RESTful semplicemente non è sufficiente per distinguerlo da qualsiasi altra API Web "RESTful". REST è diventato un termine generico o qualsiasi API Web basata su risorse e nuovi nomi come l' API Hypermedia  sono stati coniati per concentrarsi sul concetto hypermedia.

Non voglio davvero sostenere l'uso di termini errati, ma penso che l'interpretazione moderna e generale di REST significhi semplicemente usare URL e verbi HTTP uniformi per la maggior parte delle persone. Non è corretto, ma chiunque conosca la definizione di Fieldings, dovrebbe anche sapere che molti altri no. D'altra parte, chiunque conosca il REST solo osservando come sono implementate le API "RESTful" esistenti, non saprà di cosa stai parlando quando menzioni vincoli REST meno noti come HATEOAS o codice su richiesta. Il fielding potrebbe non piacere, ma penso che sia troppo tardi per tornare alla definizione originale *. E siamo onesti: se senti qualcuno parlare della sua API REST per la prima volta, pensi immediatamente che non includa l'ipermedia, vero?

Insistere sulla corretta definizione di RESTful di solito crea solo ulteriore confusione. Come per molti termini che hanno cambiato il loro significato nel tempo o che le masse hanno semplicemente adottato qualcosa di sbagliato, apprezzo se qualcuno conosce la definizione originale ma non correggerei nessuno che sta utilizzando l'interpretazione moderna più ampia di REST.

_{* e anche troppo tardi per stabilire nuovi termini per API non ipermediali simili a REST, del resto. Come dovremmo chiamarli comunque? ... RESTish ?}

È un'interfaccia CRUD (Crea, Leggi, Aggiorna, Elimina) su HTTP.

Non riesco a pensare ad alcuna autorità che sostenga questa affermazione, quindi spero che tu ottenga risposte sempre migliori.

Puoi chiamarlo come preferisci, le persone tendono ad aggrapparsi (quasi religiosamente) a qualsiasi parte delle "specifiche" del REST che non stai seguendo e utilizzarlo come un punto di protesta che è altamente dannoso per lo sviluppo. Detto questo, il semplice fatto è che esistono (quasi) zero servizi che implementano un vero REST per i loro servizi API.

Nel nostro team abbiamo chiamato il nostro Stateless APImentre era in fase di sviluppo perché avevamo un'API SOAP legacy e state legacy che stavamo sostituendo (l'API legacy stessa non ha mai avuto un nome concordato e significativo, quindi non siamo rimasti troppo presi dai nomi ).

Ora questo progetto ha solo un'API che si chiama semplicemente the <project> API. Quando alla fine lo sostituiremo, la nuova API sarà semplicemente conosciuta come the new <project> API.

Dare un nome interno fantasioso e descrittivo è quasi insignificante a meno che tu non abbia così tante API che devi differenziare questo dal resto (nel qual caso probabilmente dovresti rinominare anche tutti gli altri).

Puoi chiamarlo un'API Web . È un termine molto ampio, ma può evitare di fare chiacchiere sul significato di altre definizioni dei tipi di API. Il termine è meno tecnico e preciso rispetto ad alternative come l' API HTTP , ma potrebbe essere un vantaggio quando si parla con persone non tecniche.

Questo termine è anche usato da Leonard Richardson (che ha definito il modello di maturità Richardson che è già menzionato un'altra risposta, una misura ben accettata per quanto un'API sia vicina a un'architettura REST). È quello che ottieni se elimini la parte "RESTful" di una " API Web RESTful ".