Come strutturare un set di URL RESTful

Naviga le tue risposte
2

Tipo di REST leggero qui ... Chiedendosi quale schema di URL è più appropriato per un'app di dati del mercato azionario (BTW, tutte le query saranno GET come il client non modifica i dati):

Esempi di schema 1: 

/stocks/ABC/news
/indexes/XYZ/news
/stocks/ABC/time_series/daily
/stocks/ABC/time_series/weekly
/groups/ABC/time_series/daily
/groups/ABC/time_series/weekly

Esempi di schema 2: 

/news/stock/ABC
/news/index/XYZ
/time_series/stock/ABC/daily
/time_series/stock/ABC/weekly
/time_series/index/XYZ/daily
/time_series/index/XYZ/weekly

Esempi di schema 3: 

/news/stock/ABC
/news/index/XYZ
/time_series/daily/stock/ABC
/time_series/weekly/stock/ABC
/time_series/daily/index/XYZ
/time_series/weekly/index/XYZ

Schema 4: Qualcos'altro ???

Il punto è che per qualsiasi dato richiesto, l'url deve incapsulare se un articolo è un titolo o un indice. E, con tutto il RESTful parla di risorse sono confuso se la mia risorsa principale sia stock & indice o time_series & news . Scusa se questa è una domanda stupida: /

Grazie!

    
posta meetamit 08.10.2012 - 22:25
fonte

2 risposte

5

I tre approcci sono approssimativamente equivalenti tra loro, indipendentemente dal modo in cui strutturate la vostra gerarchia. Ciò porta a un'osservazione interessante: dopo tutto non ci può essere gerarchia.

Considera questa alternativa: 

/news/stock;ABC
/news/XYZ;index
/time_series/daily;stock;ABC
/time_series/stock;ABC;weekly
/time_series/XYZ;daily;index
/time_series/index;weekly;XYZ

Questa struttura URI offre una proprietà importante del tuo servizio: le risorse che esponi non sono di natura gerarchica, quindi qualsiasi UIR significativo dovrebbe fare.

Puoi portarlo al massimo e rendere il tuo URI simile a questo: 

/news/stock?symbol=ABC
/news/index?symbol=XYZ

o anche così: 

/time_series?frequency=daily&kind=stock&symbol=ABC

Sebbene non siano di bell'aspetto, queste alternative offrono anche valide alternative e offrono una maggiore flessibilità nel modo in cui i clienti possono costruire le loro richieste consentendo che le informazioni di identificazione vengano fornite in modo arbitrario.

    
risposta data 08.10.2012 - 23:10
fonte
0

TL; DR: Scheme 3

Se si supportano solo le singole risorse "foglia", allora non fa molta differenza. Se si considera l'estensione delle funzionalità a GETing delle raccolte; quindi penso che lo schema 3 diventi la scelta più ovvia. Crea una gerarchia più utilizzabile per l'interrogazione. Puoi ottenere tutte le notizie rilevanti per quell'utente o eventualmente filtrate da qualsiasi attributo. I dati delle serie temporali potrebbero anche essere resi più interessanti se il filtro fosse supportato, quindi potrei richiedere tutte le voci che sono andate al di sopra o al di sotto di una soglia.

    
risposta data 24.03.2014 - 09:06
fonte

Leggi altre domande sui tag

Fai udibile Ding! suono, o notifica ringhio, quando finisce 'rake test'! Utilizzo di storie utente completate per stimare le future storie utente