Come configurare queste risorse dell'API REST [chiuso]

Naviga le tue risposte
0

Sono ancora nella fase di progettazione della mia API REST e sono un po 'bloccato su come configurare le risorse. L'API verrà utilizzata dai dispositivi mobili (Android, iOS e Windows). Comunicazione tramite HTTPS.

Queste sono le funzionalità supportate dall'API:

  1. Visualizza un elenco di prenotazioni precedenti
  2. Visualizza una precedente prenotazione
  3. Crea una nuova prenotazione
  4. Crea una nuova prenotazione anonima

Stavo pensando di nominare le mie risorse come segue:

  1. API / utenti / {id} / prenotazioni (GET)
  2. API / utenti / {id} / prenotazioni / {id} (GET)
  3. API / utenti / {id} / prenotazioni (POST)
  4. API / utenti / 0 / prenotazioni (POST)

Non sono sicuro che la risorsa per 4 sia un buon progetto?

Anche 1, 2, 3 richiedono all'utente di avere un account e di essere autenticato. L'autenticazione verrà eseguita utilizzando un token di accesso. Ciò significa che l'utente deve accedere in ogni periodo X.

È sbagliato memorizzare l'ID utente sul dispositivo in modo che sia in grado di eseguire richieste in cui è richiesto l'ID utente? O dovrei semplicemente rimuovere / users / part dalla risorsa e chiedere al server di decidere in base al token di accesso che l'utente sta tentando di eseguire un'azione specifica?

L'API REST verrà creata utilizzando ASP.NET MVC4.

    
posta Supercell 14.11.2013 - 19:00
fonte

1 risposta

2

Di cosa tratta la tua domanda? Prenotazioni o utenti?

Il fatto che le prenotazioni possano essere fatte anonimamente è un dato negativo che la tua domanda riguarda le prenotazioni e che gli utenti sono "solo" un modo per rendere più facile per i visitatori di ritorno effettuare una prenotazione (non dover compilare i loro dettagli di nuovo).

Poiché le prenotazioni possono ovviamente esistere senza un utente, non ci dovrebbe essere bisogno di fingere un utente quando si pubblica una prenotazione.

Tutto ciò porta all'inevitabile conclusione che le prenotazioni dovrebbero venire prima. E che l'URI dovrebbe rispecchiare questo.

Pubblicare una prenotazione anonima è facile come una torta:

  • POST a /api/reservations

E la pubblicazione di una prenotazione da parte di un utente specifico può anche essere gestita da questo URI. L'id utente dell'ID utente connesso è già noto con altri mezzi e non dovrebbe essere necessario ripeterlo nell'URI. Come ti piacerebbe che io, come utente connesso, effettui una prenotazione usando il tuo ID utente (che potrebbe essere facilmente ricavato dall'URI) e quindi che la tua carta di credito sia addebitata?

Mettere le prenotazioni al primo posto quando si tratta di recuperarle porta a URI come questi:

  • RICEVI a /api/reservations

per tutte le prenotazioni effettuate dall'utente loggato e per le prenotazioni effettuate da un utente diverso dall'utente loggato, potresti avere

  • RICEVI a /api/reservations/users/{id} o
  • RICEVI a /api/reservations?user={id}

Le prenotazioni effettuate da una persona diversa dall'utente registrato dovrebbero probabilmente essere una funzione riservata agli amministratori. In quanto tale sembra più come filtrare / cercare.

Mentre utilizzare gli ambiti URI per filtrare è abbastanza accettabile, porta la limitazione che l'aggiunta di campi su cui filtrare può diventare un dolore. L'utilizzo dei parametri di query è più naturale per i criteri di filtro, con l'ulteriore vantaggio sarà molto più semplice estendere il numero di campi che possono essere utilizzati come criteri di filtro.

    
risposta data 14.11.2013 - 20:51
fonte

Leggi altre domande sui tag

Modelli per il login di manutenzione Chi dovrebbe fornire il Requisito doc / SRS? [duplicare]