Abbastanza confuso su ciò che costituisce lo stato corrente di una risorsa

• links to related resources : immagina una risorsa "chat_room". I link alle persone in quella stanza cambieranno man mano che vanno e vengono.

In altre parole, le relazioni di una risorsa con altre risorse possono cambiare.

• links that represent a transition... : un esempio è l'impaginazione. La risorsa potrebbe avere un link "successivo" che rimanda alla pagina 2 dalla pagina 1, pagina 3 dalla pagina 2, ecc.

Ma la risorsa potrebbe essere una sorta di macchina a stati. Quindi una risorsa "auto" potrebbe avere collegamenti a "start_engine" se è stata interrotta. Potrebbe link a "speed_up", "slow_down" e se la velocità è abbastanza lenta, "stop_engine".

In altre parole, link per la transizione ad altri stati validi, in base allo stato corrente.

(Questo non è l'esempio più REST-ful, ma per trasmettere l'idea ...)

• The results of evaluating business rules : immagina che un'università abbia una risorsa "studente". Potrebbe esserci un collegamento a "register" in una classe, un link a "apply for housing" e link a "tune in", "turn on" e "drop out". Ogni collegamento può cambiare lo stato dell'oggetto o può fornire informazioni appropriate per lo stato della risorsa. Ad esempio, il modulo di domanda per gli alloggi per studenti è adatto in modo specifico per la situazione dello studente.

...

But even though E has one-to-many relationship with its child entities, we don't consider that relationship as also representing the current state of E.

Penso che sia solo una differenza nelle metodologie. Ad esempio, in una tabella di database, non includerei record relativi a una tabella nella tabella stessa; avresti chiavi esterne nell'altra tabella, oppure un array di associazioni. Quindi, proprio come il tuo esempio, lo stato di un record in una tabella di database non include riferimenti ad altre cose (di solito).

In una vista orientata alle risorse, il libro dice che puoi contenere quei link nella risorsa stessa, come parte della definizione della risorsa.

Si noti che non hanno per farlo in quel modo. Potresti ancora avere una risorsa "chat_room", una risorsa "persona" e una risorsa "chat_room_person". Ma sembra più naturale gestire i dati strutturati per raggruppare insieme le informazioni "chat_room" e "chat_room_person".

...

Mi spiace, ho appena aggiunto una virgola per chiarezza: "transizione ad altri stati validi, in base allo stato corrente"

...

Di solito quando rappresentiamo una macchina a stati, diciamo semplicemente "Questo è lo stato: ON". Il cliente deve sapere quali transizioni sono disponibili ora che la cosa è attiva.

In REST, l'obiettivo è eliminare la comunicazione all out-of-band. Quindi integriamo lo stato (ON) con i collegamenti che rappresentano tutte le transizioni valide per quello stato.

Quindi vogliamo evitare più documentazione. La rappresentazione delle risorse può dirci: "Questo è il posto in cui mi trovo, ed è qui che posso andare dopo".

...

related resources themselves don't represent the current state of a resource. Instead, only links to these related resources represent the current state of a resource

Questa è una domanda complicata, perché il significato di "Risorsa" in REST è così straordinariamente ampio. La risposta è, sì, se definisci la tua risorsa in questo modo. E no se non lo fai.

Ad esempio, la "chat_room" potrebbe avere un elenco di link a "persone" nella chat room. Oppure potrebbe includere solo il JSON per ciascuna di queste persone. Se la tua risorsa include i dati nidificati, significa che i dati fanno parte dello stato?

È giusto dire che lo stato della chat non include lo stato delle persone in esso. Ma si trasforma in un tipo di "Uno, ma non lo stesso", che dipende da come lo definisci.

...

in REST they do represent the current state of a resource is because REST is build around that assumption

Penso che sia una dichiarazione giusta. Non ho mai individuato le implicazioni filosofiche di questo, ma in pratica funziona in questo modo.

Ancora una volta, l'idea è di rappresentare il più possibile, in modo che non sia necessaria alcuna comunicazione fuori banda. Questa è la motivazione per far rotolare tutto questo in una Risorsa.

Proverò a rispondere con un altro esempio e ad usare del codice per spiegare.

a) why would "links to related resources" also represent the current state of a resource?

Considera questa classe e supponiamo che si tratti dell'implementazione della risorsa REST /Human , che si astragga da vero live (pseudo-codice Python-ish):

class Human:
  offsprings = [] # array of links (e.g. object id) to other Humans
  age = 20
  def is_adult():
     return age >= 20
  def is_parent():
     return len(offsprings) > 0 

peter = Human()
print peter.is_parent()
=> False

kate = Human()
peter.offsprings.append(kate.id)
print peter.is_parent()
=> True

Ora chiaramente is_parent rappresenta un'informazione di stato. Ma questo stato è uno che può essere risolto solo conoscendo i link agli oggetti correlati .

b) I also don't quite understand why "Links that represent a transition to a possible future state of the current resource" also represent the the current state.

Considera un'estensione della risorsa precedente:

class Human:
  offsprings = [] # array of links (e.g. resource id) to other Humans
  avg_expected = [...] # array of statistic resources by birth date
  age = 20
  year_of_birth=1994
  def is_adult():
     return age >= 20
  def is_parent():
     return len(offsprings) > 0
  def live_expectancy():
     # consider the [ ] operator to look up the respective resource
     return avg_expected[year_of_birth] - age 

Ancora, live_expectancy è un'informazione di stato per questa risorsa. E rappresenta un possibile stato futuro, vale a dire la fine della vita. Ma senza il link alla risorsa statistics , è impossibile dirlo.