Now each request for the same URL may give you a different representation. Does it violet any constraint of REST?
Non intrinsecamente. Dipende da come la richiesta è diversa.
- Se sono diversi nel tempo (come suggeriscono le ultime notizie), allora va benissimo.
- Se vengono lanciati da utenti diversi che ricevono contenuti personalizzati, va bene anche
- Se sono diversi in base alla conoscenza implicita delle azioni passate di questo utente, non va bene, in quanto ciò significa che stai monitorando / facendo affidamento su uno stato utente e quindi non stai lavorando senza stato.
In order to serve latest news, a server must do some tracking which is the internal state of the server.
Lo "stato" in "stateless" si riferisce a uno stato utente . Non sono abbastanza sicuro di cosa intendi per stato del server, ma se vuoi dire cose come controllare il database (o una terza parte) per le ultime notizie, questo è ovviamente ammissibile.
Ad esempio, supponiamo che l'utente carichi la pagina, che chiama /latest_news/ (senza parametri) e quindi riceve articoli A,B,C . Mentre legge questi articoli, D e E vengono aggiunti al server.
Un secondo utente chiama /latest_news/ (senza parametri) e riceve A,B,C,D,E .
In un secondo momento, il primo utente chiama di nuovo /latest_news/ (nessun parametro), e tu intendi solo dargli D,E perché ha già visto A,B,C .
L'ultima parte in corsivo è il problema. Stai facendo affidamento sulla conoscenza degli articoli che l'utente ha già letto, il che significa che stai monitorando il loro stato.
How can I represent something like “latest news” in REST api?
In parole povere, i tuoi valori di ritorno non possono essere decisi in base a cose che hai tracciato segretamente sull'utente (parametri impliciti).
Ciò che sarebbe accettabile, tuttavia, sta usando i parametri espliciti . Ad esempio, /latest_news/?since=C (che recupera tutti gli articoli caricati dopo C) è perfettamente accettabile, poiché il server sta dando al cliente esattamente ciò che chiede esplicitamente.