Il più grande blocker per l'adozione di REST? [chiuso]

Question

Il più grande blocker per l'adozione di REST? [chiuso]

#1 da (0 voti)

-2

Lasciatemi essere sincero: adoro i vincoli RESTful per le applicazioni software basate su rete, specialmente quando attraversano i confini dell'organizzazione.

Detto questo, trovo che i vincoli RESTful vadano contro i requisiti di business stabiliti dalle persone sopra di me:

"No, dobbiamo mantenere lo stato client sul server per mantenere il client snello."
" No, non possiamo usare hypermedia, perché perché non restituiamo tutti i record tutto il tempo per i dati di cui abbiamo bisogno."
"No, non possiamo fare in modo che il client faccia richieste diverse, dobbiamo renderlo facile per loro."

Potrebbe la caduta dell'adozione dell'approccio RESTful nei team di software la necessità di avere più clienti intelligenti?

rest

posta edev 10.08.2016 - 10:15

fonte

1 risposta

Leggi altre domande sui tag rest

Ruota una matrice sul posto, spostando gli elementi? (Come scrivere una parte di flusso / logica dopo aver compreso il problema?) Stampa di report di cristallo da un servizio Web a una stampante di rete

score 0 · Accepted Answer

Contrastampa:

Il caso di utilizzo più comune per l'implementazione dei servizi Web al giorno d'oggi consiste nel fornire un'API JSON a un programma client. Quali sono i vantaggi tangibili che il REST completo fornisce a un'API JSON che una semplice API GET e POST (o anche solo POST) non fornisce già in modo più semplice?

Per dirla in altro modo, se REST è così grande, perché non usiamo REST ovunque? Perché non scrivere semplicemente tutti i nostri metodi di classe seguendo anche la semantica REST?

Ipoteticamente, potrei creare un'API JSON la cui semantica deve coincidere con un metodo di controllo sul server. Questo metodo potrebbe essere qualsiasi cosa e potrebbe richiedere un numero qualsiasi di parametri. Decido che la mia regola empirica sarà utilizzare GET per i metodi che restituiscono un valore e POST per i metodi che non lo fanno. Questa non è chiaramente la semantica di REST, ma è perfettamente sensata dal punto di vista del design.

HTTP ha alcune stranezze che possono rendere difficile allineare la semantica API di un'applicazione con esso. Ad esempio, posso usare i parametri del modulo con POST, ma non GET. Questo è un buon motivo per utilizzare semplicemente POST ovunque, se il tuo unico obiettivo è implementare un'API a cui un programma client può comunicare è il più semplice e diretto possibile.