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

Chiamala una API HTTP .

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

Gli standard HTTP definiscono risorse, verbi, intestazioni, negoziazione del contenuto, ecc.

REST (REpresentational State Transfer) è un'architettura con requisiti che possono essere soddisfatti dagli standard HTTP esistenti, ma HTTP funziona da solo.

Secondo la mia esperienza, il 90% delle "API HTTP REST" dovrebbe chiamarsi "solo" un'API HTTP.

Non vergognarti di lasciare l'etichetta REST. Come con i microservizi e i database non relazionali, non è necessario avere un'API RESTful per essere cool. Roy si proponeva di creare l'architettura di applicazione in rete più longeva, compatibile con le versioni precedenti che potesse. 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. (SOAP)
1. POST ovunque. Endpoint multipli. (Risorse)
2. VERBI HTTP. Endpoint multipli.
3. Come 2 e restituisce collegamenti alle risorse. (RESTful)

Quindi, secondo il modello, lo chiamerei un webservice conforme a richardson livello 2 o qualcosa del genere.

link

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

Non voglio veramente sostenere l'uso di termini errati, ma penso che l'interpretazione generale moderna di REST significhi semplicemente utilizzare URL uniformi e verbi HTTP per la maggior parte delle persone. Non è corretto, ma chiunque conosca la definizione di Fieldings, dovrebbe anche sapere che molti altri non lo fanno. D'altra parte, chiunque conosca REST solo osservando come sono implementate le API "RESTful" esistenti, non saprà di cosa si sta parlando quando si menzionano vincoli REST meno noti come HATEOAS o codice on-demand. Fielding potrebbe non piacermi, 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, presumi immediatamente che non includa l'ipermedia, vero?

Insistere sulla corretta definizione di RESTful di solito crea solo ulteriore confusione. Come con molti termini che hanno cambiato il loro significato nel tempo o che le masse hanno semplicemente adottato in modo errato, apprezzo se qualcuno conosce la definizione originale, ma non correggerei nessuno che stia usando la più ampia interpretazione moderna di REST.

_{* e anche in ritardo per stabilire nuovi termini per le API non ipermetriche simili a REST, se è per questo. Come dovremmo chiamarli comunque? ... RESTish ?}

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

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

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

Nel nostro team abbiamo nominato il nostro Stateless API mentre era in sviluppo perché avevamo un'API SOAP statica e funzionale legacy che stavamo sostituendo (l'API precedente non ha mai avuto un nome concordato e significativo, quindi non abbiamo essere troppo preso dai nomi).

Ora questo progetto ha solo un'API è chiamato semplicemente the <project> API . Quando alla fine lo sostituiremo, la nuova API sarà semplicemente chiamata the new <project> API .

Assegnare un nome interno di fantasia e descrittivo è quasi priva di significato a meno che non si abbiano così tante API da dover differenziare questa dal resto (nel qual caso probabilmente dovresti rinominare anche tutte le altre).

Puoi chiamarlo Web API . Si tratta di un termine molto ampio, ma può evitare di snellire il significato di altre definizioni del tipo di API. Il termine è meno tecnico e preciso rispetto alle alternative come 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 Richardson Maturity Model che è già menzionato un'altra risposta - un misura accettata per quanto è vicina un'API a un'architettura REST). È ciò che ottieni se lasci cadere la parte "RESTful" di " RESTful Web API ".