Se una risorsa API ha più endpoint?

2

Dovrebbe essere disponibile una risorsa attraverso più di un endpoint URL?

Ad esempio, dispongo di risorse per gli esami che contengono più risorse di domande che a loro volta contengono più risorse di risposta. Gli endpoint per elencare le domande e visualizzare una singola domanda sono i seguenti:

/api/exams/{exam_id}/questions
/api/exams/{exam_id}/questions/{question_id}

Tuttavia, ha anche senso poter visualizzare una singola domanda con un endpoint come:

/api/questions/{question_id}

È una cattiva idea supportare endpoint aggiuntivi per una singola risorsa? Se è una cattiva idea, penso che preferirei endpoint complessi per collezioni e singole risorse, perché sembra incoerente semplificare un solo endpoint e avere il seguente:

/api/exams/{exam_id}/questions
/api/questions/{question_id}

Andando ancora oltre, c'è anche la complessità degli endpoint delle risorse a risposta multipla.

/api/exams/{exam_id}/questions/{question_id}/answers
/api/exams/{exam_id}/questions/{question_id}/answers/{answer_id}


/api/questions/{question_id}/answers
/api/questions/{question_id}/answers/{answer_id}


/api/answers/{answer_id}
    
posta mcon 24.08.2017 - 18:33
fonte

1 risposta

1

Should a resource be available through more than one URL endpoint?

Solo se ne hai bisogno. Hai?

Is it a bad idea to support additional endpoints for a single resource?

Potrebbe essere una cattiva idea solo se non ne hai bisogno.

Prendi in considerazione che le API REST sono contratti. Una volta in produzione, cambiare questi contratti può essere davvero impegnativo. Nel complesso, se siamo obbligati a supportare la retrocompatibilità. Il dover mantenere il codice YAGN rientra nel nostro interesse, quindi è preferibile rilasciare solo il codice funzionale.

Come facciamo a sapere se ne abbiamo bisogno?

Leggi attentamente i requisiti perché, questo è piuttosto un bisogno implicito .

Ad esempio:

  1. Gli esami devono essere impostati solo con domande disponibili . Diciamo che gli esami sono impostati per raccogliere domande da un repository. Se questo è il caso, l'API dovrebbe fornirci questo repository . Il repository -essenzialmente- è la raccolta /api/questions .

  2. Alcuni ruoli possono aggiungere nuove domande per un ulteriore utilizzo in diversi esami . Qui, stiamo assumendo diverse cose: 1) le domande non necessariamente appartengono a un esame, 2) le domande possono essere gestite in modo indipendente, 3) le domande possono appartenere a diversi esami. Ognuno di questi casi ti porterà a fornire all'API un repository di domande.

  3. Le domande degli esami sono composte dal riferimento alla sua formulazione e dalla sua risposta valida, dalla risposta confermata, dalle note a margine del valutatore, dal punteggio, ecc. . Qui, stiamo assumendo che entrambi gli URI non stiano identificando la stessa risorsa. Le domande nell'ambito di applicazione / contesto di un esame sono diverse rispetto alle domande esaminate dal repository.

It's not a requirement, but it's simple to add additional endpoints in the current implementation. I think the only need for it currently would be to simplify endpoints and make them slightly more intuitive.

Ponderare i pro e amp; contro di questo "leggermente più intuitivo" . Se i benefici del così piccolo miglioramento superano i costi di YAGNI (di solito non lo fanno), allora prendi il controllo. Altrimenti, dimenticalo.

Letture che potresti essere interessato

risposta data 28.08.2017 - 09:25
fonte

Leggi altre domande sui tag