Estou um pouco confuso sobre como os URLs funcionam. Antigamente, quando eu estava aprendendo HTML e outras coisas, eu sabia que o que vem depois do nome de domínio é o local de um arquivo que queremos carregar (por exemplo website.com/somefolder/somefile.html). E era simples, eu conseguia entender.
Recentemente tive que aprender mais algumas coisas sobre web e vi que URLs são mais complicados. Por exemplo:
- links drupal são como somewebsite.com/node/43
- As solicitações REST são como somewebsite.com/books/32
- depois '?' você pode passar alguns parâmetros
Como isso funciona? Como o servidor (ou algo mais? Sou bastante novato) sabe o que URL significa quando recebe uma solicitação? Poderia ser:
- localização do recurso
- visualização drupal
- Solicitação REST
- algumas outras coisas?
Não sei se minha pergunta faz sentido, espero que você entenda do que se trata minha confusão.
Responder1
Como isso funciona?
O servidor decide.
Como o servidor (ou algo mais? Sou bastante novato) sabe o que URL significa quando recebe uma solicitação?
O servidor depende de sua configuração. Para servidores baseados em Unix, isso geralmente é tratado por um ou mais arquivos de texto, geralmente chamados de arquivos de "configuração". Ao configurar o servidor, você pode especificar isso. Os detalhes sobre como especificar isso variam de acordo com o software de servidor web que você usa.
(Tende a haver muitos tutoriais para servidores web populares e pacotes CGI, então se um administrador de site não sabe como fazer isso, essa pessoa geralmente começa a ler exemplos/documentação/tutoriais. Então, se você procurar documentação sobre um servidor web como o Apache, você provavelmente encontrará informações sobre como configurar o Drupal. Por outro lado, se você procurar informações sobre algo como o Drupal, provavelmente encontrará uma seção de documentação sobre como configurar o Apache. use o Drupal. Com tanta documentação disponível, os administradores de sites geralmente não precisam se esforçar muito para encontrar detalhes relevantes para os pacotes de software que desejam usar.)
O cliente HTTP 1.1 tende a dividir a URL em 3 partes:
- O protocolo (por exemplo, http/https)
- O site (por exemplo, example.com)
- o recurso (por exemplo, /somedir/file.htm)
Isso pode ser uma ligeira simplificação exagerada. Alguns URLs mais antigos permitiam algo comoftp://nomedeusuário@senha:exemplo.com/somedir/fileembora os navegadores mais recentes tendam a remover esse suporte, por exemploMS KB 8344389, por questões de segurança (incluindo uma quantidade notável de abusos que ocorreram, por exemplohttp://paypal.com/gibberish%40PhishingSite.example.com/gibberishconverteria% 40 em ASCII 64, que é o @, fazendo com que o nome de usuário paypal.com/gibberish fosse usado para fazer login em PhishingSite.example.com, que simplesmente aceitaria o login e pediria às pessoas sua senha do PayPal. As pessoas veriam paypal.com no início do URL e confiariam nele.
Claro, existem alguns "padrões" como # em uma URL que é algo que o cliente web reconhecerá e não enviará isso ao servidor. Em vez disso, o cliente web tratará o texto após o # como texto âncora para onde ir. Além disso, % é usado para escapar de caracteres hexadecimais. Os clientes da Web tendem a entender isso.
Outros detalhes podem ficar por conta do servidor. Por exemplo, muitos servidores web possuem ? iniciando uma lista de parâmetros e usando & (ou muitos pontos e vírgulas?) para dividir os parâmetros dentro da lista de parâmetros. No entanto, esse é simplesmente um comportamento comum exibido por muitos servidores web. Não há nenhuma parte do HTTP que force os servidores web a honrar isso. Na verdade, o servidor web pode lidar com isso da maneira que desejar, e o cliente web provavelmente não exigirá nenhum suporte especial para isso.
Se você já configurou um servidor HTTP, provavelmente entenderá que parte dessa configuração especifica o que fazer com os recursos solicitados. por exemplo, você poderia dizer que tudo enviado para / carregará arquivos da área /srv/httpdocs/ do disco rígido local, exceto /cgi-bin/ que executará um programa localizado em /cgi-bin/, e qualquer coisa abaixo de /scripts / e terminando com .pl serão executados pelo interpretador PERL.
Os detalhes específicos variam de acordo com a configuração do servidor web, portanto não existe um padrão universal que diga ao cliente web se ele pode receber uma cópia de uma página estática ou a saída de um programa que é executado. Tudo o que o cliente web pode esperar é que, se solicitar um recurso, o servidor web responderá a ele.
Responder2
O servidor web nãosaberqualquer um desses significados – em todos os casos, ele apenas recebe o caminho do recurso, executa-o no programa principal do site e envia a saída resultante. E é claro que diferentes programas fazem coisas diferentes com o caminho que lhes foi dado.
Se não houver nenhum programa configurado, ele procura um arquivo com esse nome e o atende diretamente. (PHP e CGI geralmente estão em algum lugar no meio: o servidor web ainda procura um arquivo, mas depois executa esse arquivoem sicomo o programa.)
Portanto, a única coisa /node/43que o torna uma "visualização Drupal" é o servidor web ter sido configurado para passar /node/<anything>para o software Drupal. A página web ainda é considerada um recurso, embora tenha sido gerada dinamicamente.
(O próprio Drupal, é claro, sabe que se o caminho começar com /node/ele, será seguido pelo ID da visualização.)
As solicitações REST também são solicitações de recursos completamente regulares; o que os torna "RESTful" é apenas o estilo e comportamento geral. (Por exemplo, URLs no estilo /book/345se enquadram na ideologia REST, mas /api/get_book?id=345não.)