Percorsi nidificati e parametri per Rails URL (Best Practice)

Question

Ho una conoscenza discreta di URL riposante e tutta la teoria che sta dietro non nidificazione degli URL, ma non sono ancora abbastanza sicuro di come questo sembra in un'applicazione enterprise, come qualcosa come Amazon, StackOverflow, o Google ...

Google ha gli URL in questo modo:

• http://code.google.com/apis/ajax/
• http://code.google.com/apis/maps/documentation/ staticmaps /
• https://www.google.com/calendar/render?tab=mc

Amazon in questo modo:

• http://www.amazon.com/books-used-books-textbooks/b/ref=sa_menu_bo0?ie=UTF8&node=283155&pf_rd_p=328655101&pf_rd_s=left-nav-1&pf_rd_t=101&pf_rd_i = 507.846 & pf_rd_m = ATVPDKIKX0DER & pf_rd_r = 1PK4ZKN4YWJJ9B86ANC9
• http://www.amazon.com/Ruby-Programming-Language-David -Flanagan / dp / 0596516177 / ref = sr_1_1? ie = UTF8 & s = libri & qid = 1.258.755,625 mila & sr = 1-1

E StackOverflow in questo modo:

• https://stackoverflow.com/users/169992/viatropos
• https://stackoverflow.com/questions/tagged/html
• https://stackoverflow.com/questions/tagged?tagnames=html&sort=newest&pagesize=15

Quindi la mia domanda è, che cosa è migliori pratiche in termini di creazione di URL per i sistemi come questi? Quando si inizia a memorizzare i parametri nell'URL, quando non è vero? Queste grandi aziende non sembrano essere seguendo le regole in modo molto dibattuto nella comunità di Ruby (che si dovrebbe quasi mai gli URL nido, per esempio), quindi mi chiedo come si fa a implementare i propri URL in progetti su larga scala, perché sembra l'idea di non nidificazione gli URL rompe in qualcosa più grande di un blog.

Qualche consiglio?

Answer 1

Non troppo impantanato dalle "regole" nella comunità di Ruby. L'idea è che non si dovrebbe andare in mare quando la nidificazione degli URL, ma quando sono appropriati sono costruiti nel quadro Rails per un motivo:. Usarli

Se una risorsa cade sempre all'interno di un'altra risorsa, nido esso. Niente di male. Andando più a fondo di quanto si possa essere a volte un po 'di dolore, perché i sentieri del percorso sarà molto lungo e possono ottenere un po' di confusione.

Inoltre, non confondere con nidificazione namespacing. Solo perché si vede example.com/admin/products/1234/edit non vuol dire che non c'è alcun avvenimento di nidificazione. Routing può rendere le cose sembrano annidati quando non sono in realtà a livello di codice.

Sono personalmente un grande fan di nidificazione e lo uso spesso (un solo livello - a volte due) nelle mie applicazioni. Inoltre, l'aggiunta di URL stile permalink che utilizzano parole piuttosto che solo gli ID sono più appetibili e possono aiutare con SEO, anche se non stanno annidati.

Answer 2

Credo che l'argomento a favore o contro REST e / o nidificazione nei tuoi percorsi ha molto a che fare con il modo che si desidera esporre la vostra API. Se non si cura di esporre mai un'API per la vostra applicazione pubblicamente, v'è un argomento da fare che il rispetto rigoroso di progettazione RESTful è una perdita di tempo, in particolare se siete d'accordo con il ragionamento dietro REST. La vostra scelta.

Trovo che pensare a come un client (diverso da un browser) potrebbe accedere alle informazioni da voi app aiuta nel processo di progettazione. Uno dei più grandi vantaggi di pensare alla progettazione della tua app dal punto di vista API è che si tende a eliminare le complessità non necessaria. Per me questo è la radice delle precauzioni che senti nella comunità Rails circostante percorsi nidificati. Mi prendo come un'indicazione che le cose sono sempre un po 'complicato e potrebbe essere il momento di fare un passo indietro e ripensare l'approccio. Sistemi "più grandi di un blog" non devono essere intrinsecamente complessa. Alcune parti potrebbero essere, ma si può anche essere sorpresi quando ci si avvicina al disegno da una prospettiva diversa.

In breve, in considerazione alcuni dei dogmi si potrebbe sentire da alcune parti della comunità come guide e segnali che si consiglia a pensare più profondamente il vostro disegno. REST Strict è semplicemente un altro modo di pensare a come si sta strutturando la propria applicazione.

Answer 3

Beh, la prima cosa da capire è che se si guardano le applicazioni di esempio e codice di esempio là fuori che Rails è buono solo per la costruzione di blog e carrelli della spesa.

Avanti vi renderete conto che le persone che sostengono gli URL RESTful e percorsi senza nidificazione probabilmente stanno costruendo solo blog e carrelli della spesa.

Alla fine ci sarà l'illuminazione e si accetterà che gli URL di RESTful e percorsi non nidificati sono un mucchio di stronzate e poi si può ottenere su realmente costruire la vostra applicazione e ottenere il lavoro svolto.