Mi sto ritrovando a creare un sacco di chiamate JSON attraverso la mia applicazione, che sono fondamentalmente azioni distribuite su vari controller. Sto pensando di creare un controller JSON per mantenere tutte le azioni JSON in un controller, quindi invece di
Products/GetListJSON
Chiamerei
JSON/Products
Potresti avere delle ramificazioni che non ho considerato? Qualcuno può pensare a validi motivi per non farlo?
Regola 1. Cool URI's Never Change. link
NON impostare i percorsi delle risorse in base alla programmazione delle "ottimizzazioni" come questa. Progetta i tuoi percorsi correttamente, indipendentemente dalle considerazioni sulla codifica. Il percorso vive per sempre. Il tuo codice verrà e verrà.
Avere il tipo di dati ("JSON" nel tuo caso) parte del percorso è disapprovato da alcuni. Sostengono che il tipo di risposta dovrebbe non essere parte del percorso RESTful verso l'oggetto.
Sostengono che il tipo di risposta dovrebbe essere codificato in un'intestazione (accetta, in particolare) e il percorso dovrebbe essere invariato.
Ad esempio, puoi fare cose come questa per raggiungere lo stesso obiettivo: invariare l'URI con la codifica non nel percorso.
/ Prodotti /? = Risposta JSON
Non sono completamente d'accordo con la loro logica.
Tuttavia, ciò che è importante è che le considerazioni sulla lingua di programmazione non guidano la progettazione del percorso per le richieste di servizi Web.
Penso che /Products.json non sia un cattivo progetto RESTful.
Ho usato la tecnica / path / to / json / resource in un paio di forme diverse.
La cosa su cui devi assolutamente fare chiarezza è la regola n. 1: gli URI fantastici non cambiano a causa del linguaggio di programmazione o delle considerazioni sugli strumenti.
Leggi altre domande sui tag architecture mvc