Implementazione di un'API REST complicata con API Web ASP.NET

3

Sto provando a creare un'API RESTful utilizzando l'API Web ASP.NET per un gioco, e qui ci sono i metodi che ho finora:

/games GET
/games/:id GET
/games POST
/games PUT
/games DELETE
/users GET
/users/:id GET
/users/:id/games GET  (fetch user's games)
/users POST
/users PUT
/users DELETE

Ho due domande:

  1. Dove posizionare il metodo / users /: id / games? Ho due controller (GamesController.cs e UsersController.cs). La risorsa che sto richiedendo è un gioco, quindi dovrebbe andare nel GamesController e passare l'userid come parametro, e lo mapperei semplicemente a / users /: id / game route?

  2. Anche se ho un metodo che restituisce una serie di giochi (/ giochi GET), in realtà non lo userei almeno inizialmente. Mostrerò invece solo 1 gioco alla volta per l'utente, e questo gioco sarà un gioco "popolare / caldo" in cui c'è molta attività e l'utente può anche prendere qualche azione (ci sono altri giochi dove l'utente non può fare alcuna azione e deve aspettare l'azione dell'avversario). Posso avere un metodo chiamato GetHotGame () che determinerà quale gioco mostrare all'utente, quando l'utente fa clic su "Avanti", ma quello che mi chiedo è quale dovrebbe essere il metodo REST?

Potrei semplicemente usare l'endpoint / games /: id e passare "hot" come id e usare il metodo GetHotGame per decidere quale gioco restituire all'utente? O dovrei usare l'endpoint / games e passare "hot" come una querystring e implementare una sorta di paging in cui il numero di pagine è solo uno? Oppure, dovrei avere un endpoint separato, qualcosa come games / hot o / hotgame?

    
posta Prabhu 17.10.2014 - 23:10
fonte

1 risposta

4

In primo luogo, un'alternativa da considerare ...

Dopo molti anni di progettazione e implementazione di servizi Web (e anche ereditando alcune implementazioni alquanto paragonabili), ho raggiunto una conclusione che anche altri hanno: Evita percorsi nidificati delle risorse.

L'articolo Suggerito per le API REST di Matthew Beale spiega il ragionamento alla base di questo. (Cerca nella sezione Modelli di prima classe .)

Ma se insisti ...

  1. Se devi (o preferisci) utilizzare percorsi di risorse nidificati, ti suggerisco di raggruppare metodi basati su che tipo di risorsa restituiscono . Quindi /users/:id/games verrebbe implementato in GamesController . Il mio ragionamento qui è che mantiene una correlazione più coerente tra le classi API e le classi DAL, che aiuta a evitare congetture in seguito e riduce il numero di dipendenze tra classi.

  2. Penso che il tuo suggerimento querystring sia il più pulito, fondamentalmente per gli stessi motivi del numero 1 (restituisce un gioco, quindi dovrebbe essere sotto la /games risorsa e implementato in GamesController ). Qualcosa come /games?keyword=hot&limit=1 ricorda lo schema di approcci API di successo e intuitivi che ho visto usati altrove.

risposta data 17.10.2014 - 23:33
fonte

Leggi altre domande sui tag