HasMany RESTfull Implementation

Question

HasMany RESTfull Implementation

Naviga le tue risposte

#1 da (4 voti)
#2 da (2 voti)
#3 da (0 voti)

2

Quindi ho letto molto sul design RESTfull, in particolare sulle risorse.

Esempio canonico di Utenti , Post e Commenti , con relazioni come:

Users ---(hasMany)---> Post ---(hasMany)---> Comment

Si potrebbe inizialmente pensare di esporre qualcosa del tipo:

GET /users               GET /posts               GET /comments 
POST /users              POST /posts              POST /comments 
GET /users/id            GET /posts/id            GET /comments/id
PUT /users/id            PUT /posts/id            PUT /comments/id
DELETE /users/id         DELETE /posts/id         DELETE /comments/id

Ma poi, dì che voglio tutti Commenti di un certo post fatto da un particolare utente . Dovrei fare qualcosa del tipo:

GET /users/id
   > someUser
   > var postIds = someUser.posts()
GET /posts?id=<postIds[0]>&id=<postIds[1]>&...
   > somePosts
   >  **application user inspects posts to see which one they care about**
   > var postOfInterest = somePosts[x]; 
   > var postId = postOfInterest.id;
GET /comments?id=postId
   > someComments (finally)

Supponiamo che mi interessi solo un post o commento nel contesto del suo proprietario. Supponiamo che una diversa struttura delle risorse possa essere (o meno?) Più naturale:

GET /users
POST /users  
GET /users/id   
PUT /users/id
DELETE /users/id

GET /users/id/posts
POST /users/id/posts
GET /users/id/posts/id
PUT /users/id/posts/id
DELETE /users/id/posts/id

GET /users/id/posts/id/comments
POST /users/id/posts/id/comments
GET /users/id/posts/id/comments/id
GET /users/id/posts/id/comments/id
GET /users/id/posts/id/comments/id

Quale per me, è probabilmente una migliore rappresentazione di quali siano le risorse. Quindi tutto ciò di cui ho bisogno è:

GET /users/id/posts
   > somePosts
   > **application user inspects posts to see which one they care about**
   > var postOfInterest = somePosts[x];
   > var postId = postOfInterest.id;
GET /users/id/posts/postId/comments
   > someComments

Questo sembra più come navigare in un file system rispetto al metodo precedente - ma non so se RESTfull (forse questo è ciò che REST stava cercando di sbarazzarsi di ) perché in Per accedere a una risorsa Commenti , ho bisogno di sapere quale utente e quale post appartiene a. Ma il primo richiede 3 richieste, mentre il secondo richiede solo 2.

Pensieri?

design architecture rest url

posta Colin Martell 01.10.2013 - 20:03

fonte

3 risposte

Leggi altre domande sui tag design architecture rest url

Esiste uno strumento che rappresenta visivamente tutti i potenziali percorsi di un particolare pezzo di codice? [chiuso] Il posto giusto per incorporare un parser: server o client?

score 4 · Answer 1

Per quanto ne so, ciò che stai descrivendo, essenzialmente risorse annidate, è perfettamente RESTful. Potresti voler mantenere le risorse come "/ posts / id" e "/ comments / id" nel caso tu voglia pubblicare post o commenti / s senza sapere quale utente stai guardando, ma non c'è niente di sbagliato con anche annidandoli l'uno dentro l'altro per ottenere i post per un particolare utente o commenti per un particolare post.

Le guide in particolare consentono di nidificare facilmente le risorse in questo modo facendo qualcosa di simile alla seguente nella configurazione dei percorsi:

resources :users do
  resources :posts do
    resources :comments
  end
end

score 2 · Answer 2

Quando esporti un'interfaccia RESTful, devi anche esaminare, ciò che l'interfaccia sta dicendo all'utente.

Quando esamini un post , è più che probabile che un utente non si preoccupi di chi lo ha creato e a meno che post ID non sia solo univoco nell'ambito di un utente (che è improbabile) il suo solo addizionale cruft nel URL. Anche se è vero che un post ha un utente , non sono così sicuro che tu possa dire che in questo contesto è posseduto dal suo utente, se la differenza è chiara.

C'è anche l'abiquità di ciò che accade quando l'utente X scrive un post e l'utente Y scrive un commento su quel post. In questo /users/idZ/post/id/comment/id idZ si riferisce all'utente che ha scritto il post o al commento? Moreso, perché hai bisogno di conoscere l'utente, se hai già un ID di post o di un commento?

In alternativa, un commento è di proprietà del suo post, anche se il suo ID è globalmente unico.

Infine, vi è una differenza di leggibilità tra users e user , con quest'ultimo che implica discrezione. Allo stesso modo, con posts e post e comments e comment .

Quindi personalmente, dato questo, userei queste azioni (con i verbi appropriati dove richiesto):

ACTION /users
ACTION /user/id   

ACTION /user/id/posts    # A user owns these posts
ACTION /post/id          # But the site owns this particular post

ACTION /post/id/comments
ACTION /post/id/comments/id

score 0 · Answer 3

Colin, immagino che il punto che stai discutendo riguardi il REST annidato e che sia completamente possibile con l'interfaccia.

Utenti --- (hasMany) --- > Posta --- (hasMany) --- > Commento

Questa relazione esiste, ma il modo in cui le hai definite nei prossimi due ha eliminato lo scopo delle rappresentazioni nidificate. Ho progettato questo codice sotto disegni annidati REST in questa pagina come riferimento dimostrativo, puoi anche controllarli.