Web Service Design: i vantaggi del piping use-cases per l'URL piuttosto che l'utilizzo di parametri di ricerca o viceversa?

Question

Web Service Design: i vantaggi del piping use-cases per l'URL piuttosto che l'utilizzo di parametri di ricerca o viceversa?

#1 da (2 voti)

2

Devo creare un webservice per le informazioni sui dipendenti e sto cercando di organizzarlo.

Per chiarire, abbiamo già un servizio REST-ish per le persone e un servizio REST-ish separato per le aziende.
Questo servizio sarà specifico per la relazione tra questi due (tutti i dati saranno consegnati dai servizi ai dati-consumatori attraverso un client (o client)).

Tra le altre attività, questo servizio dovrà:

recupera tutti i datori di lavoro (ID della società) per un dato ID di persona
recupera tutti i dipendenti (id di una persona) per un determinato ID di azienda

Potrei vedere fare questo un paio di modi diversi.

L'utilizzo dei parametri di ricerca potrebbe sembrare qualcosa come:
- http://blah/employee/find?person_id=12345
- http://blah/employee/find?company_id=9876
L'uso dell'URL potrebbe sembrare qualcosa come:
- http://blah/employee/find/employers?id=12345
- http://blah/employee/find/employees?id=9876

Prendendo l'approccio dell'URL, sarei in grado di validare in modo specifico un singolo parametro per ciascun caso employer e employee .. sembra bello e pulito, ma abbastanza fisso. < br> L'approccio ai parametri sembra essere meno rigido / più flessibile, ma richiede più percorsi di dati (se / altro), e quindi il codice può richiedere più tempo per capire quando il futuro-me (o chiunque altro) ritorna dopo è stato a lungo dimenticato.

Quali benefici potrebbero esserci per andare una volta contro l'altra?
Per me, la differenza sembra un po 'arbitraria, ma questa è la prima volta che devo prendere questa decisione.

architecture web-services url

posta mOrloff 17.01.2014 - 20:51

fonte

1 risposta

Leggi altre domande sui tag architecture web-services url

calcolo se i tempi di servizio sono soddisfatti La consistenza finale è una soluzione sbagliata per le applicazioni di e-commerce?

score 2 · Answer 1

Vorrei andare con le rotte REST e in questo caso le risorse annidate. Questo è in qualche modo simile al tuo secondo approccio, solo gli ID diventano anche parte dell'URL. In questo caso, i tuoi URL saranno simili a questo:

http://blah/company/123/employees
http://blah/employees/789/companies

Sebbene molto dipenda dal modo in cui il tuo modello funziona e dalla capacità della tua catena di strumenti di aiutare con il routing RESTful. Il mio suggerimento viene dal punto di vista di un programmatore di Rails (e in qualche modo il semplice fatto che REST è un buon standard che i consumatori del tuo servizio dovrebbero essere in grado di capire facilmente)

Per Rails in questo caso ci sarebbero due controllori: aziende e dipendenti. Dall'URL il controller richiesto otterrebbe i parametri. Per i primi parametri URL [: company_id] sarebbe impostato su 123. E nell'azione indice del controller dipendenti che verrebbe chiamato in quel caso, farei semplicemente:

Company.find(params[:company_id]).employees

Viceversa per il secondo indice URL nel controller delle aziende si farebbe:

Employee.find(params[:employee_id]).companies

Quindi non c'è davvero alcuna ripetizione. Le attività sono chiare per entrambi i controller. L'URL corretto conduce alla risorsa che desideri. L'annidamento degli URL definisce le dipendenze tra tali risorse. Si tratta di due finzioni piuttosto distinte e in realtà dovrebbe risiedere in posizioni diverse invece di provare a forzarle in un'unica posizione. I responsabili dei dipendenti elencano i dipendenti, le società di elenchi dei controllori delle società. Non posso davvero essere più chiaro di quello.

Da qui può dipendere da chi sono i consumatori del tuo servizio. Se sono sviluppatori, dovrebbero capirlo (e probabilmente sanno già come funziona REST). Se non lo sono, dovresti ottenere una sorta di pagina di ricerca che elenchi le aziende e consenta loro di selezionarne una (e simili per i dipendenti). Quindi questa pagina di ricerca si collegherebbe all'URL corretto e non dovrebbero preoccuparsi di cosa sia esattamente quell'URL.