Fornecendo URLs amigáveis ​​para um site versus realidades de IDs de banco de dados

Temos um banco de dados de recursos, sejam eles produtos, postagens em blogs ou algo assim. Precisamos criar um esquema de URL para endereçá-los, para o site público.

Aqui estão dois exemplos vinculados ao ID do banco de dados:

• https://www.youtube.com/watch?v=7FPS6llqhXw

• http://www.amazon.co.uk/gp/product/B000NHOMSQ

Aqui está um exemplo amigável:

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

(Um pequeno vislumbre da minha vida de navegação lá)

Gosto dos URLs amigáveis, pois você tem uma idéia sobre o que está no final do URL quando passa o mouse ou o vê em um email ou documento. É melhor para SEO, ou costumava ser.

O que acontece quando o documento ou produto é renomeado? Ou porque mudou (o Wiki pode não mudar, mas nossos recursos podem) ou devido a um erro de digitação, certo? Nossos recursos são muito técnicos, palavras longas e propensas a erros.

Além disso, temos um ID do banco de dados, que é um número. Vejamos uma ideia para o endereço de um vídeo usando uma loja de aluguel fingido:

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

O ID é óbvio e é usado na consulta ao banco de dados. Bem.

O bit das portas deslizantes não é exclusivo e apenas é gerado a partir do título do vídeo, pode ser verificado no GET, portanto, se as portas deslizantes foram inseridas e não correspondem ao que realmente está no documento 287171, ele responde 404.

Ou talvez isso possa ser ignorado, permitindo que os humanos colem o que quiserem lá dentro, se alguém quiser. Portanto, este URL também funcionaria:

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

O problema da verificação da parte amigável é, como mencionado, o problema de renomear ou corrigir erros de digitação. Se o nome foi alterado e, em nosso domínio, isso não acontece, não queremos quebrar os URLs existentes, então devemos:

• Só não verifique a parte amigável.

• Verifique, mas adicione um 'histórico' de partes amigáveis ​​ao registro do banco de dados para que quaisquer IDs amigáveis ​​anteriores ainda funcionem!

Seus pensamentos e idéias são bem-vindos.

Luke

Manter o ID no URL é o método à prova de futuro e, como você demonstrou, os URLs ainda podem parecer relativamente bons.

Outra opção usada por vários projetos é manter um histórico de lesmas usadas anteriormente. Quando o título muda, você atualiza a lesma e, se alguém tentar procurar uma lesma obsoleta, pesquise na lista de lesmas antigas. Dessa forma, lesmas antigas podem ser reutilizadas para novo conteúdo (ou não, dependendo da sua implementação).

O Wordpress fez isso e a gema friendly_id, que é provavelmente a gema mais usada para gerenciar identificações amigáveis ​​do Rails.

Além disso, embora eu goste de URLs com boa aparência, acho importante lembrar que esse é provavelmente um recurso usado por usuários mais experientes em tecnologia. Alguns navegadores estão começando a ocultar URLs (ou parte dele).

Eu usei dois cenários diferentes no passado.

1. /id/some-slugonde o idé usado para procurar , a lesma não. Assim, a lesma pode ser qualquer coisa . Porém, quando a lesma não corresponde à lesma real, o usuário é redirecionado para a versão atual.

2. /permalinkpara casos em que não desejamos um ID no URL ou onde o URL nunca deve mudar, mesmo que exista um ID disponível (consulte [1] e [2] ). Obviamente, nesse caso, o permalinké usado para a pesquisa . O slug atual e o link permanente (o primeiro slug) são armazenados no banco de dados.

De nenhuma dessas maneiras, você precisa manter um histórico de lesmas em seu banco de dados, o que seria problemático muito em breve.

ps: no segundo caso, você precisará de um roteamento muito específico para manter os créditos sociais:

• se você quiser, redirecione os usuários para o URL atual (sem link permanente)
• tem o link permanente usado como o URL nos botões sociais
• sempre redirecione o rastreador do facebook para o link permanente

Veja [1] e [2] novamente.

O que acontece quando o documento ou produto é renomeado?

A resposta HTTP 301 (Movida) foi projetada para esta finalidade. Se algum cliente acessar o URI antigo, basta enviar o novo URI e ele poderá redirecionar para ele.

O bit das portas deslizantes não é exclusivo e apenas é gerado a partir do título do vídeo, pode ser verificado no GET, portanto, se as portas deslizantes foram inseridas e não correspondem ao que realmente está no documento 287171, ele responde 404.

Se eu seguir corretamente, este é um trabalho duplicado, você tem um identificador de nome para o recurso e um ID no mesmo URI. Isso não serve para nada.

Se você está preocupado com vários filmes com o mesmo nome, pode adicionar informações extras sobre o filme ao URL

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

ou

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

Dito isto, não há nada de errado em usar IDs se isso fizer sentido para o seu modelo de dados, principalmente se a única coisa que você agrupa é que são vídeos.

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

O cliente, um computador ou um usuário humano, não deve confiar muito na estrutura do URI, em primeiro lugar, deve estar observando o conteúdo que você retornou para descobrir qual recurso encontrar.

Não há nada de errado em ter um sistema URI sensível que facilita a alguém adivinhar a localização de um recurso ou navegar para cima e para baixo na estrutura com base em propriedades compartilhadas (ou seja, todos os filmes em 2004), mas seu sistema não deve confiar sobre isso e nenhum cliente deve quebrar se você alterar seus URIs

Ou, dito de outra maneira, você poderá mudar durante a noite de

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

para

http://vidsyeah.com/video/12323

e nenhum cliente deve interromper porque os clientes devem procurar conteúdo e não URLs.

A BBC usa lesmas que são:

• alfanumérico (para compacidade)
• exclusivo (para pesquisas)
• não sequencial (para que as coisas adicionadas ao banco de dados não sejam expostas)

por exemplo, http://www.bbc.co.uk/programmes/b006mk7h

Cada programa público tem um ID e uma lesma. Os IDs podem ser números inteiros com incremento automático, como de costume, e as lacunas não são expostas.

Do ponto de vista do RESTful, os URIs devem seguir uma estrutura hierárquica previsível e talvez para melhorar a usabilidade.

Isso os tornará mais fáceis de usar pelos consumidores. Se seus dados tiverem relacionamentos, será necessário algum tipo de hierarquia.

Parece que o esquema é: \video\[name]\[id]

Se o nome não estiver sendo usado para outra classificação, ele poderá ser descartado em favor de \video\[id].

No entanto, se você deseja classificar os vídeos, talvez o nome seja útil.

Exemplos:

• \ video \ SwingingDoors \ 123
• \ video \ SwingingDoors \ 124
• \ video \ SlidingDoors \ 125
• \ video \ SlidingDoors \ 126

É realmente uma decisão de design sobre como o acesso é modelado.