Servizio RESTful e DAO: decidere le risposte

3

Sto sviluppando un'API RESTful e sto utilizzando DAO per fornire i dati al servizio.

Ho difficoltà a decidere dove alcune responsabilità dovrebbero cadere, sia nel servizio o nel contratto DAO. O non solo responsabilità, ma solo decidere cosa dovrebbe o non dovrebbe fare ogni componente.

Nello scenario della parte CRUD dell'API, concentriamoci sulla funzionalità di creazione, ad esempio. Quando una risorsa viene creata (o meno), quale risposta è prevista dal servizio? L'oggetto serializzato che è stato creato? Un messaggio vero / falso? Niente? Questo è ciò che intendo:

// Option 1
@POST
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public Resource createResource(Resource resource) {
    dao.create(resource);
    return resource;
}

// Option 2
@POST
@Consumes(MediaType.APPLICATION_JSON)
public void createResource(Resource resource) {
    dao.create(resource);
}

// Option 3
@POST
@Consumes(MediaType.APPLICATION_JSON)
public String createResource(Resource resource) {
    return dao.create(resource); // or even a custom message?
}

Ma andando oltre. Cosa dovrebbe restituire il DAO? Il metodo dao.create() deve restituire un valore booleano? Dovrebbe restituire l'oggetto creato o null se non può essere creato? O solo essere void ?

// Option 1
public Resource create(Resource resource) {
    return resources.add(resource) ? resource : null;
}

// Option 2
public void create(Resource resource) {
    resources.add(resource);
}

// Option 3
public boolean create(Resource resource) {
    return resources.add(resource);
}

Voglio solo capire cosa ci si aspetta da un servizio RESTful e poi, decidere quale sia la migliore divisione di "chi dovrebbe fare cosa".

O sto solo pensando troppo a questo e qualsiasi implementazione ha un senso ed è buona come l'altra?

    
posta dabadaba 03.06.2016 - 15:14
fonte

2 risposte

3

È frequente che i DAO restituiscano la risorsa appena creata, in particolare quando un ORM viene utilizzato dietro le quinte, per un paio di motivi a cui posso pensare:

  1. L'oggetto restituito ha spesso la sua serie di chiavi primarie surrogate, ma soprattutto -

  2. L'oggetto restituito è spesso collegato alla sessione del database in modo da poter eseguire automaticamente ulteriori modifiche quando la sessione viene chiusa.

Nel tuo esempio questo non è terribilmente importante, ma è conveniente quando è coinvolta la logica aziendale più complessa. Nessuna delle opzioni incluse segue questo modello.

Come per gli endpoint REST, sono d'accordo con Eric, ma aggiungerei che al momento della creazione, rispondere con il codice di stato 201, l'intestazione Location impostata sull'URL canonico della nuova risorsa e la risorsa serializzata stessa nel corpo della risposta . L'opzione 1 si avvicina di più a questo.

    
risposta data 03.06.2016 - 16:49
fonte
3

Per motivi di prestazioni, è bello se una chiamata API HTTP che crea una risorsa restituisca una rappresentazione di tale risorsa al client. Altrimenti devono fare una chiamata GET separata per ottenere la risorsa.

Il successo o il fallimento della richiesta dovrebbe essere trasmesso dal codice di stato nella risposta: codici 2xx per il successo, codici 4xx e 5xx per errori. Non dovresti mai avere * bisogno di inviare un messaggio o un valore booleano che indica il successo o l'insuccesso, ma nel caso di un errore dovresti inviare un messaggio che indica cosa è andato storto.

[*] Ad alcune persone piace comunque, perché può essere conveniente per alcuni clienti avere queste informazioni nella risposta. Questo è in aggiunta al codice di stato, non al posto di.

    
risposta data 03.06.2016 - 16:02
fonte

Leggi altre domande sui tag