Orientamento alle risorse non è davvero orientato agli oggetti?

Question

Quando ci pensi, il paradigma REST di essere orientato alle risorse si riduce a essere orientato agli oggetti (con funzionalità vincolata, sfruttando il più possibile l'HTTP)?

Non sto necessariamente dicendo che è una cosa negativa, ma piuttosto che se sono essenzialmente lo stesso molto simili, allora diventa molto più facile capire REST e le implicazioni che tale architettura comporta.

Aggiornamento: Ecco alcuni dettagli più specifici:

1. Le risorse REST sono equivalenti alle classi pubbliche. Le classi / risorse private non sono semplicemente esposte.
2. Lo stato della risorsa equivale a metodi o campi pubblici di classe. I metodi / campi / stati privati ??non sono semplicemente esposti (ciò non significa che non sia presente).
3. Sebbene sia certamente vero che REST non mantiene lo stato specifico del client tra le richieste, non mantiene lo stato delle risorse su tutti i client. Le risorse hanno lo stato, allo stesso modo in cui le classi hanno lo stato.
4. Le risorse REST sono identificate in modo univoco a livello globale da un URI allo stesso modo in cui gli oggetti server sono identificati in modo univoco a livello globale dal loro indirizzo di database, nome della tabella e chiave primaria. Concesso che non esiste (ancora) un URI per rappresentarlo, ma puoi facilmente costruirne uno.

Answer 1

REST è simile a OO in quanto entrambi modellano il mondo come entità che accettano messaggi (cioè metodi) ma oltre a ciò sono diversi.

L'orientamento agli oggetti enfatizza l'incapsulamento di stato e opacità , utilizzando tutti i metodi diversi necessari per operare sullo stato. REST riguarda il trasferimento di (rappresentazione dello) stato e trasparenza . Il numero di metodi utilizzati in REST è limitato e uniforme su tutte risorse. Il più vicino a quello in OOP è il metodo ToString () che è molto più o meno equivalente a un HTTP GET.

L'orientamento agli oggetti è stateful : fai riferimento a un oggetto e puoi chiamare metodi su di esso mantenendo lo stato all'interno di una sessione in cui l'oggetto è ancora nell'ambito. REST è apolide - tutto ciò che vuoi fare con una risorsa è specificato in un singolo messaggio e tutto ciò che devi sapere riguardo a quel messaggio viene rispedito in una singola risposta.

Nell'orientamento agli oggetti, non esiste un concetto di identità universale dell'oggetto : gli oggetti ottengono l'identità dal loro indirizzo di memoria in qualsiasi momento, un UUID specifico del framework o da una chiave di database. In REST tutte le risorse sono identificate con un URI e non devono essere istanziate o eliminate: esistono sempre nel cloud a meno che il server non risponda con un 404 non trovato o 410 Andato , nel caso in cui tu sappia che non esiste alcuna risorsa con quell'URI.

REST ha garanzie di sicurezza (ad esempio, un messaggio GET non cambierà stato) e idempotenza (ad esempio, una richiesta PUT inviata più volte ha lo stesso effetto di solo Una volta). Sebbene alcune linee guida per particolari tecnologie orientate agli oggetti abbiano qualcosa da dire su come determinati costrutti influenzano lo stato, in realtà non c'è nulla sull'orientamento degli oggetti che dica qualcosa sulla sicurezza e l'idempotenza.

Answer 2

Penso che ci sia una differenza tra dire che un concetto può essere espresso in termini di oggetti e dire che il concetto è lo stesso dell'orientamento degli oggetti.

OO offre un modo per descrivere i concetti REST. Ciò non significa che REST stesso attui OO.

Answer 3

Hai ragione. Dan Connolly ha scritto un articolo al riguardo nel 1997. Ne parla anche la Tesi sul fielding .

Answer 4

Gli oggetti raggruppano lo stato e funzionano insieme. L'orientamento alle risorse riguarda la modellazione esplicita dello stato (dati), la limitazione della funzione ai verbi predefiniti con semantica universale (nel caso di HTTP, GET / PUT / POST / DELETE), e lasciando il resto dell'elaborazione al client.

Non esiste un equivalente per questi concetti nel mondo dell'orientamento agli oggetti.

Answer 5

Solo se i tuoi oggetti sono DTO ( Oggetti di trasferimento dati ) - poiché non puoi hanno davvero comportamenti diversi dalla persistenza.

Answer 6

Sì, il tuo parallelo all'orientamento agli oggetti è corretto.

Il fatto è che la maggior parte dei servizi web (REST, RESTful, SOAP, ..) può passare informazioni sotto forma di oggetti, quindi non è ciò che le rende diverse. SOAP tende a portare a un minor numero di servizi con più metodi. REST tende a portare a più servizi (1 per tipo di risorsa) con poche chiamate ciascuno.

Answer 7

Sì, REST riguarda il trasferimento di oggetti. Ma non è l'intero oggetto; solo lo stato corrente dell'oggetto. L'assunto implicito è che le definizioni di classe su entrambi i lati del REST sono potenzialmente simili; altrimenti lo stato dell'oggetto è stato forzato in qualche nuovo oggetto.

REST si occupa solo di 4 eventi della vita di un oggetto, crea (POST), recupera (GET), aggiorna (PUT) ed elimina. Sono eventi significativi, ma ce ne sono solo quattro.

Un oggetto può partecipare a molti altri eventi con molti altri oggetti. Tutto il resto di questo comportamento è completamente al di fuori dell'approccio REST.

C'è una relazione stretta - REST sposta gli oggetti - ma dire che sono gli stessi riduce i tuoi oggetti a raccolte passive di bit senza metodi.

Answer 8

REST non riguarda solo gli oggetti, ma anche le proprietà: una richiesta post a / users / john / numero_profilo con un nuovo numero di telefono non sta aggiungendo un nuovo oggetto, sta impostando una proprietà dell'oggetto utente 'john'

Questo non è nemmeno l'intero stato dell'oggetto, ma solo una modifica a una piccola parte dello stato.

Non è certamente una partita 1: 1.