API REST: Come disaccoppiare questo controller?

Question

API REST: Come disaccoppiare questo controller?

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

0

Ho due tipi di entità: Utente e Riprendi. Quindi il mio istinto mi ha detto di scrivere due controller.

Terminali UserController:

/users 
/users/{id} 
/users/{id}/resumes

Endpoint di ResumeController:

/resumes
/resumes/{id}
/resumes/searchBy[?criteria={criteria}]

L'utente ha un riferimento per riprendere, quindi per crearne uno faccio un POST a /users/{id}/resumes . Altrimenti un POST a /resumes/{id_user}/ non sembra essere RESTful, non è vero?

È giusto avere questi due controller? sebbene il primo abbia un riferimento del servizio del secondo controller:

class UserController {

    UserService userService;
    ResumeService resumeService;

}

Dovrei combinarli?

api-design rest

posta anat0lius 07.07.2017 - 16:52

fonte

3 risposte

Leggi altre domande sui tag api-design rest

Approccio alla progettazione del software per un grande database relazionale Come creare un metodo factory

score 3 · Answer 1

La domanda a cui penso tu debba rispondere è: il tuo UserController dovrebbe gestire la creazione del curriculum?

Che è più un problema di separazione delle preoccupazioni.

Quando si tratta di decidere come nominare i diversi comportamenti della propria API, è necessario comprendere il concetto di The Uniform Interface . Le basi possono essere capite (molto vagamente) come: you should use a standards based approach when designing an API . Il link spiega abbastanza bene questi standard.

Ecco i miei 2 centesimi. Supponendo un'API Content-Type: application/json

Vorrei creare un curriculum come POST su /resume e richiedere un oggetto json body con una proprietà userId . Un errore verrebbe generato se non fosse fornito e l'API non avrebbe intrapreso alcuna azione. %codice% E per la risposta vorrei restituire il { ... "userId": 1234 ... other resume stuff } che verrebbe creato nel database.

In definitiva, sai come dovrebbe essere consumata la tua API.

score 1 · Answer 2

Potresti davvero modellarlo in entrambi i modi. Mi sembra abbastanza naturale che /users/{id}/resumes sia utilizzato per CRUD riprende l'utente e che /resumes sarebbe un endpoint solo per query. Nulla dice che l'API e il database devono mappare uno a uno. Soprattutto per le query, di solito trovo che ho bisogno di più rappresentazioni dei dati. Spesso vale anche la pena mantenere un view / table / data store separato per supportare le esigenze speciali delle query. Per esempio ricerca full text.

score 1 · Answer 3

Si noti che questi endpoint sono equivalenti:

/users/{id}/resumes
/resumes/searchBy?user_id={id}

Consentire di separare ResumeService dal tuo UserController .

Come puoi vedere da quanto sopra, /users/{id}/resumes è in realtà un filtro sulla raccolta, quindi ha più senso pubblicare sull'intera collezione: /resumes .