Zapewnianie przyjaznych adresów URL dla witryny internetowej a realia identyfikatorów baz danych

24

Mamy bazę danych, niezależnie od tego, czy są to produkty, posty na blogu czy coś takiego. Musimy zaprojektować schemat adresów URL, aby je rozwiązać, dla publicznej witryny internetowej.

Oto dwa przykłady związane z identyfikatorem bazy danych:

Oto przykład, który jest przyjazny:

http://en.wikipedia.org/wiki/LED_circuit

(Trochę rzutu oka na moje życie przeglądania tam)

Lubię przyjazne adresy URL, ponieważ masz pojęcie o tym, co znajduje się na końcu adresu URL po najechaniu myszą lub zobaczeniu w e-mailu lub dokumencie. Tak jest lepiej dla SEO, albo kiedyś.

Co się stanie, gdy nazwa dokumentu lub produktu zostanie zmieniona? Albo dlatego, że się zmienił (Wiki nie może się zmienić, ale nasze zasoby mogą) lub z powodu literówki, prawda? Nasze zasoby są bardzo techniczne, długie słowa i podatne na błędy.

Ponadto mamy identyfikator bazy danych, który jest liczbą. Spójrzmy na pomysł na adres filmu za pomocą udawanego wypożyczalni:

http://vidsyeah.com/video/sliding-doors/287171

Identyfikator jest oczywisty i jest używany w wyszukiwaniu DB. W porządku.

Bit drzwi przesuwnych nie jest unikalny i właśnie został wygenerowany z tytułu wideo, można go zweryfikować przy pomocy GET, więc jeśli wprowadzono drzwi przesuwne i nie pasują one do tego, co naprawdę jest w dokumencie 287171, odpowiada 404.

A może można to zignorować, pozwalając ludziom trzymać tam, co im się podoba, jeśli komuś na to zależy. Więc ten adres URL również działałby:

http://vidsyeah.com/video/anything-at_all/287171

Problem z weryfikacją części przyjaznej polega, jak wspomniano, na problemie zmiany nazwy lub korekty literówki. Jeśli nazwa się zmieni, a w naszej domenie tak się stanie, nie chcemy rozkładać adresów URL, które tam są, więc powinniśmy:

Tylko nie weryfikuj przyjaznej części.
Zweryfikuj, ale dodaj „historię” przyjaznych części do rekordu bazy danych, aby wszystkie poprzednie przyjazne identyfikatory nadal działały!

Twoje myśli i pomysły są mile widziane.

Luke

— Luke Puplett
źródło

11

nawet ta strona używa kombinacji http://programmers.stackexchange.com/questions/255684/providing-friendly-urls-for-a-website-vs-realities-of-database-ids(używając wersji niezweryfikowanej w świetle zmian tytułu, również krótszy link „udostępnij” to tylko id: http://programmers.stackexchange.com/q/255684/25768(i identyfikator użytkownika do śledzenia odznak)

— maniak ratchet

11

Jeśli masz unikatowy identyfikator w adresie URL, nie rozumiem, dlaczego w ogóle chcesz zweryfikować część dotyczącą ślimaka. Użyj go do wyglądu i zignoruj go do wyszukiwania.

— thorsten müller

Jeśli któryś z was chce udzielić prawidłowej odpowiedzi, zagłosuję, żebyście dostali punkty. Pozwolę, aby głosy weszły i udzieliły odpowiedzi głosującym, którzy otrzymali najwięcej głosów za kilka dni.

— Luke Puplett

1

programmers.stackexchange.com/questions/231483/…

— gnat

3

Nigdy wcześniej nie znałem terminu ślimak. Musiałem być pod kamieniem. Geddit?

— Luke Puplett

6

Przechowywanie identyfikatora w adresie URL jest metodą sprawdzającą się w przyszłości, a jak wykazano, adresy URL mogą nadal wyglądać stosunkowo dobrze.

Inną opcją stosowaną w wielu projektach jest przechowywanie historii wcześniej używanych ślimaków. Gdy tytuł się zmienia, aktualizujesz ślimak i jeśli ktoś próbuje szukać przestarzałego ślimaka, wyszukaj na liście starych ślimaków. W ten sposób stare ślimaki mogą być ponownie wykorzystane do nowej zawartości (lub nie w zależności od implementacji).

Wordpress to zrobił, podobnie jak klejnot przyjazny_id, który jest prawdopodobnie najczęściej używanym klejnotem do zarządzania przyjaznymi identyfikatorami dla Railsów.

Ponadto, chociaż lubię dobrze wyglądające adresy URL, myślę, że należy pamiętać, że jest to prawdopodobnie funkcja używana przez bardziej doświadczonych użytkowników. Niektóre przeglądarki zaczynają nawet ukrywać adresy URL (lub ich część).

— Mbillard
źródło

2

Rozważałem tę historię ślimaków. Od czasu opublikowania pytania zauważyłem wiele dużych nazwanych witryn, które nie są sprawdzane, dlatego możesz je zmienić, aby cokolwiek powiedzieć. amazon.co.uk/Blah-Blah-Blah/dp/B004R276L8 działa. StackExchange jest sprytny, ponieważ „poprawia” i przekierowuje przeglądarkę, aby zapewnić, że odpowiedni link zostanie wyświetlony i udostępniony.

— Luke Puplett

„Ślimak” jest mniej przydatny dla ludzi, a bardziej przydatny do optymalizacji pod kątem wyszukiwarek, ponieważ „ślimak” lub „przyjazny adres URL” powinien zawierać słowa kluczowe związane z zawartością strony. Zaawansowani użytkownicy nie są powodem do umieszczania przyjaznych adresów URL w Twojej witrynie. Głównym powodem są rankingi wyszukiwarek.

— Greg Burghardt,

Nie zgadzam się. Trudno jest pracować z adresami URL zawierającymi tylko identyfikatory; trudno jest zapamiętać z listy, do której możesz chcieć wrócić. Lub czy na drugim końcu linku będzie coś niestosownego. Pasek adresu Chrome sugeruje również dowolną część adresu URL, co jest przydatne.

— Luke Puplett,

1

@LukePuplett tak uważam, że sposób radzenia sobie z adresami URL przez SE jest najłatwiejszy, jeśli chodzi o ślimaki.

— mbillard

@GregBurghardt jedyną różnicą jest współczynnik klikalności, użytkownicy zwykle klikają nieco więcej w przyjaznych adresach URL: stackoverflow.com/questions/505793/…

— mbillard

3

W przeszłości korzystałem z dwóch różnych scenariuszy.

/id/some-sluggdzie służy do wyszukiwania , pocisk nie. Tak więc ślimak może być czymkolwiek . Ale jeśli ślimak nie pasuje do faktycznego ślimaka, użytkownik zostaje przekierowany do bieżącej wersji.id
/permalinkw przypadkach, gdy nie chcieliśmy mieć identyfikatora w adresie URL lub gdzie adres URL nie powinien się nigdy zmieniać, nawet jeśli jest dostępny identyfikator (patrz [1] i [2] ). Oczywiście, w tym przypadku służy do odnośnika . Zarówno bieżący ślimak, jak i bezpośredni link (pierwszy ślimak) są przechowywane w bazie danych.permalink

W żadnym z tych sposobów nie trzeba przechowywać historii ślimaków w bazie danych, co wkrótce stałoby się problematyczne.

ps: W drugim przypadku będziesz potrzebować bardzo konkretnego routingu, aby zachować kredyty społecznościowe:

jeśli chcesz, przekieruj użytkowników do bieżącego adresu URL (bez bezpośredniego łącza)
mieć link bezpośredni używany jako adres URL w przyciskach społecznościowych
zawsze przekierowuj przeszukiwacz Facebooka do bezpośredniego łącza

Zobacz ponownie [1] i [2] .

— Żyła
źródło

Dlaczego będzie to problematyczne? Jeśli zatrzymam, a identyfikator i ślimak są czymkolwiek, odwiedzający przejdzie do faktycznej strony. Czy będzie to szkodliwe dla SEO?

— Jnanaranjan

Masz na myśli prowadzenie historii ślimaków? Co robisz, gdy ktoś chce ponownie użyć takiego ślimaka? Dla tego samego lub innego identyfikatora? Jak zaprojektować bazę danych i / lub kod, aby zapobiec wielokrotnym przekierowaniom? Czy chcesz ukryć istnienie po usunięciu i czy przekierowania ujawniają poprzednie istnienie? Wszystko to nie jest niemożliwe, ale rodzi wiele pytań, którym raczej po prostu zapobiegam z założenia.

— Lode

Chciałem powiedzieć, że jeśli identyfikator jest obecny w adresie URL, to niezależnie od tego, co to jest, zostanie przekierowany na żądaną stronę. Zatem historia ślimaków nie ma znaczenia. Zgadzam się, że jest to problematyczne dla Androida.

— Jnanaranjan

1

Ah, dobrze. To właśnie dodałem scenariusz 1, prawda? Czy masz na myśli coś innego?

— Lode

Tak. To jest poprawne.

— Jnanaranjan

2

Co się stanie, gdy nazwa dokumentu lub produktu zostanie zmieniona?

W tym celu zaprojektowano odpowiedź HTTP 301 (przeniesiona). Jeśli jakiś klient przejdzie do starego identyfikatora URI, wystarczy wysłać mu nowy identyfikator URI i można do niego przekierować.

Bit drzwi przesuwnych nie jest unikalny i właśnie został wygenerowany z tytułu wideo, można go zweryfikować przy pomocy GET, więc jeśli wprowadzono drzwi przesuwne i nie pasują one do tego, co naprawdę jest w dokumencie 287171, odpowiada 404.

Jeśli wykonam poprawnie, to jest powielanie pracy, masz zarówno identyfikator nazwy zasobu, jak i identyfikator w tym samym URI. To nie służy żadnemu celowi.

Jeśli martwisz się, że wiele filmów ma tę samą nazwę, możesz dodać dodatkowe informacje o filmie do adresu URL

http://vidsyeah.com/video/2000/sliding_doors
http://vidsyeah.com/video/1932/sliding_doors

lub

http://vidsyeah.com/video/studios/paramount/sliding_doors
http://vidsyeah.com/video/studios/warnerbros/sliding_doors

Powiedziawszy, że nie ma nic złego w używaniu identyfikatorów, jeśli ma to sens dla twojego modelu danych, szczególnie jeśli jedyną rzeczą, którą grupujesz, jest to, że są to filmy.

http://vidsyeah.com/video/210232
http://vidsyeah.com/video/2342

Klient, zarówno komputer, jak i człowiek, nie powinien przede wszystkim polegać na strukturze identyfikatora URI, powinien poszukać treści, którą zwróciłeś, aby dowiedzieć się, który zasób znaleźć.

Nie ma nic złego w posiadaniu rozsądnego systemu URI, który ułatwia odgadnięcie lokalizacji zasobu lub nawigację w górę i w dół struktury na podstawie wspólnych właściwości (tj. Wszystkich filmów w 2004 r.), Ale twój system nie powinien polegać i żaden klient nie powinien się zepsuć, jeśli zmienisz swoje URI

Innymi słowy, powinieneś mieć możliwość zmiany z dnia na dzień

http://vidsyeah.com/video/studios/paramount/sliding_doors

do

http://vidsyeah.com/video/12323

i żaden klient nie powinien się zepsuć, ponieważ klienci powinni patrzeć na treść, a nie na adresy URL.

— Cormac Mulhall
źródło

Podobnie jak odpowiedź Jona, myślę, że nie nosisz kapelusza UX, kiedy o tym myślisz. Chcę zwiększyć użyteczność adresu. Zobacz mój komentarz w pytaniu: „Podoba mi się przyjazne adresy URL, ponieważ masz pojęcie o tym, co znajduje się na końcu adresu URL, gdy najedziesz na niego myszą lub zobaczysz go w wiadomości e-mail lub dokumencie. To jest lepsze dla SEO, albo kiedyś”.

— Luke Puplett

2

Aby rzucić 301, musiałbym być w stanie wyszukać odpowiedni zasób, dlatego potrzebowałbym historii.

— Luke Puplett

1

Potrzebujesz historii, ale jeśli masz witrynę z zasobami, które się zmieniają, to i tak dobry pomysł.

— Cormac Mulhall

Nie ma problemu z przyjaznymi identyfikatorami URI. Nie zrobiłbym schematu, że identyfikator URI może być dowolny, ale nadal działa, jeśli ma na końcu identyfikator. To tak naprawdę nie rozwiązuje żadnego problemu (użytkownik wciąż musi pamiętać identyfikator) i wprowadza mylący schemat identyfikatora URI (użytkownik może słusznie zapytać, dlaczego dwa różne identyfikatory URI, jeden z błędem w pisowni, idą do tego samego zasobu)

— Cormac Mulhall

1

Jeśli obawiasz się błędów ortograficznych w identyfikatorach URI, powszechnym sposobem radzenia sobie z tym jest sugerowanie URI na stronie błędu 404 dla niepoprawnie napisanego adresu URL. Możesz wyszukiwać wzorce słów i zwracać to, co według Ciebie może być poszukiwane przez użytkownika.

— Cormac Mulhall

1

BBC używa ślimaków, które są:

alfanumeryczny (dla zwięzłości)
unikalny (dla wyszukiwań)
niesekwencyjny (aby kolejność dodawania rzeczy do db nie była ujawniona)

np. http://www.bbc.co.uk/programmes/b006mk7h

Każdy program publiczny ma zarówno identyfikator, jak i ślimak. Identyfikatory mogą być jak zwykle liczbami całkowitymi z automatyczną inkrementacją, a luki nie są ujawniane.

— Nicholas Shanks
źródło

0

Z punktu widzenia RESTful, identyfikatory URI powinny mieć przewidywalną i hierarchiczną strukturę, aby zwiększyć użyteczność.

Ułatwi to korzystanie z nich przez konsumentów. Jeśli Twoje dane mają relacje, konieczna byłaby jakaś hierarchia.

Wygląda na to, że schemat to: \video\[name]\[id]

Jeśli nazwa nie jest używana do dalszej klasyfikacji, może zostać odrzucona na korzyść \video\[id].

Jeśli jednak chcesz sklasyfikować filmy, być może nazwa jest przydatna.

Przykłady:

\ video \ SwingingDoors \ 123
\ video \ SwingingDoors \ 124
\ video \ Drzwi przesuwne \ 125
\ video \ Drzwi przesuwne \ 126

To naprawdę decyzja projektowa dotycząca sposobu modelowania dostępu.

— Jon Raynor
źródło

Myślę, że myślisz o tym z interfejsu API / architektury informacji o witrynie PoV. Chciałem wprowadzić część generowanego przyjaznego adresu URL, aby pomóc ludziom i SEO. Najwyraźniej jest to powszechna rzecz i nosi nazwę „ślimak”. Nazwa nie jest używana do klasyfikacji i jest dodawana (nie usuwana), aby poprawić UX z adresem URL i naszą witryną / marką.

— Luke Puplett