FUNDAMENTOS DA ARQUITETURA CLIENTE-SERVIDOR
Resumo
Este documento apresenta os fundamentos da Arquitetura Cliente-Servidor, explicando-os sua importância, funcionamento e redigindo a possíveis usabilidades da mesma no nosso atual momento, objetivando, sintetização e apresentação da melhor forma, todo esse conceito e sua metodologia.
Palavras-chave: Arquitetura Cliente-Servidor, Servidor, Cliente, Arquitetura Rest;
Introdução
Este relatório tem como objetivo demosntrar e caracterizar, de forma conceitual, os fundamentos da Arquitetura Cliente-Servidor, desde seu conceito teórico até suas vantagens e desvantagens como sistema. Dentro dos fundamentos, temos o método HTTP e seus usos, funcionamento do status code HTTP, comparação entre HTTP e HTTPS, conceitos de URL, URI e URN, os request Headers e como funciona os Body e Media Type dentro de toda Arquitetura Rest.
Arquitetura Cliente-Servidor
O termo Arquitetura Cliente-Servidor, ou como é chamado Modelo Cliente-Servidor, apresentasse como uma distribuição computacional que é responsável pela manutenção da informação e conseguimento dos dados através de dois indivíduos: Cliente e Servidor. Dentro destes indivíduos, seguimos com os métodos que interligam-as, denominados HTTP, sendo referenciado, o seu fluxo e arquitetura.
A entidade Cliente, tem como funcionamento fazer a primeira comunicação direta com o servidor, compartilhando seus dados e tipicamente requisitando os serviços conectados a esse servidor, interligando ao processo de aplicação da rede. Seguindo nesse caminho, o servidor compartilha seus serviços realizando um processo entre o agente usuário e o software que o interfaceia, executando o programa dentro de um host (sendo ele o mesmo ou necessitando de dois pontos diferentes, assim, precisando comunicar-se com um protocolo da camada de aplicação), normalmente em um fluxo básico de processamento, utilizando a Arquitetura Rest. Realizando esses processos, a aplicação servidora revela um serviço de endereço (URL), devolvendo-a com uma resposta a requisição do software do agente usuário.
Em relação a suas vantagens e desvantagens, a Arquitetura Cliente-Servidor possibilita inúmeras vantagens dentro de todo o processo do sistema, dentre elas: Escalabilidade de performance, trazendo a melhor performance para o sistema web com os componentes de um fluxo básico, Manutenibilidade de Hardware (fácil matunenção em relação ao hardware), Maior Segurança de Dados (Utilizando HTTPS), grande compatibilidade em qualquer que seja a arquitetura do cliente, de fácil uso e totalmente cacheável (viabilidade do uso de cache para armazenamento dos dados). Enquanto desvantagens, temos os altos custos para aplicação da arquitetura, sobrecarregamento do servidor com o aumento das solicitações dos clientes e, por nao possuir uma certa resistência de uma rede P2P, qualquer falha crítica em uma máquina diretamente ligada ao servidor, o mesmo interrompe e não completa as solicitações atribuída aos clientes.
Como dito anteriormente, a Arquitetura Rest é implantanda de forma que fique claro o funcionamento da ligação cliente-servidor e de que foram bem definidas a criação do projeto dentro dos princípios e definições necessárias. A sigla REST significa “Representational State Transfer” ou “Transferência de Estado Representacional” qualificando, dentro da arquitetura web, de forma abstrata.
HTTP vs HTTPS
HTTP e HTTPS são protocolos de tranferência de hipertexto (HyperText Transfer Protocol) que são padrões para Web. Basicamente, através deles, os navegadores fazem uma requisição das páginas solicitadas, em texto, logo, todos os dados enviados e transmitidos são protocolados em texto, tanto para o servidor quanto ao usuário, podendo ser interceptados ou não no meio do caminho.
Nesse contexto, diferenciamos o HTTP do HTTPS por um único elemento, o SSL. O SSL (Secure Locker Layer), se resume no processo de criação de chaves públicas e privadas criptografadas, possibilitando a segurança de toda comunicação da rede (Servidor — Usuário).
Body, Media Type e Headers
Na Arquitetura Cliente-Servidor, toda informação é enviada e recebida de forma que não possua qualquer tipo de interferência na ligação Usuário-Servidor, com isso, todas as Requests possuem seus “Body’s” e “Media Type’s”, que tem como definição, os dados fornecidos, ou seja, Body, como o nome diz, é o corpo da informação, enquanto o Media Type é o tipo de dado dentro desse Body. A grande maioria dos Media Types utilizados são: “text/plain”, sendo ele um texto simples/puro com conteúdo de um arquivo sequecial ordinário legível, “text/html” é o diretório de uma página solicitada, porém em forma HTML (HyperText Markup Language), “image/jpeg” sendo uma ligação de compressão de um arquivo como resultado uma imagem, “video/mp4” a compressão de um arquivo de vídeo, entre outros.
Juntamente com os “Body’s” e “Media Type’s”, temos o “Header”, traduzindo de forma literal, como cabeçalho, de todas essas informações requisitadas desde autoridade, método, path, scheme, etc. O Header tem a função de fornecer adições dinâmicas da requisição, dados utilizados pelo cliente, servidor ou até mesmo da aplicação.
Métodos HTTP
Dentro da Arquitetura Cliente-Servidor, possuímos diferentes métodos que são aqueles que distribuem as funções entre o cliente e servidor, assim, concluindo ou não a prestação de serviços. Chamamos esses de métodos HTTP. Sobredito, os métodos são compostos por “EndPoint” (O ponto final do serviço), Método (como chamamos ele) e a sua função dentro da arquitetura.
Figura 1 — Métodos HTTP
Fonte: Marcus Beckenkam, 2016
Como podemos visualizar, existe os seguintes métodos: GET, POST, GET{id}, PUT, PATCH e DELETE, sendo todos necessitados de um “Endpoint” para realização de uma resposta do servidor ao agente usuário. O método GET, tem como funcionalidade, a leitura de dados, sendo retornado um Status Code 200, caso seja aceito pelo servidor, ou 400, finalizando que não funcionou a requisição feita, já o GET{id} retorna o dado (ou usuário) com o “id” solicitado pelo GET, especificando ainda mais o dado. No próximo método, temos o POST, utilizado mais frequentemente para criação de recursos. Em seguida, o PUT que substitui esses dados ligados a esse “id”, requisitando que o recurso seja armazenado em uma URI, sendo assim, caso não exista, crie-o e caso exista, atualize-o. Com o método PATCH, alteramos e atualizamos os dados em partes desse “id”. E o DELETE, como o nome diz, exclui o recurso especificado por completo do sistema.
Esses métodos possibilitam fazer a ligação do cliente aos serviços disponíveis no servidor, porém, do mesmo jeito, é necessário realizar a verificação desses serviços diretamente com o servidor, de forma que o mesmo responda e mande os dados. Desta forma, existe códigos, sobredito, que basicamente demonstra para o usuário o estado da requisição, e o chamamos de HTTP Status Code. O HTTP Status Code é divido em códigos que vão de 100 á 599, juntamente com seus significados:
Figura 1I — HTTP Status Codes
Fonte: Kamal Nayan, 2015
Os códigos são divididos em 5 categorias de apresentação: 100–199: Código informacional, indicando as prováveis respostas e ações; 200–299: Códigos de sucesso, informando que a requisição foi concluída; 300–399: Códigos de redirecionamento, redirecionamento de arquivos e seus caminhos dentro do sistema, normalmente indicando um novo endereço; 400–499: Códigos de erro do Cliente, indica algum erro por conta de requisição do cliente ao servidor; 500–599: Códigos de erro do Servidor, indica erro por conta de requisição do servidor ao cliente (Kamal Nayan, 2015);
Tendo em vista a usabilidade dos códigos, existem aqueles que são mais utilizados dentro de um sistema, sendo eles:
200 — OK: Requisição foi executada com sucesso;
201 — Created: A requisição cria um recurso diretamente no servidor;
202 — Accepted: Requisição foi aceita e está em processo de conclusão;
301 — Moved Permanently: Servidor redirecionou o cliente para uma outra URL/URI;
400 — Bad Request: Falha na requisição por dados errados ou insuficientes do cliente;
401 — Unauthorized: Falha ao acessar uma página protegida por uma senha e o usuário não possuir permissão de acesso;
403 — Forbidden: Usuário reconhecido mas sem acesso para tal recurso;
404 — Not Found: Recurso solicitado não encontrado;
405 — Method not allowed: Requisitando um método que não é permitido;
500 — Server Error: Erro no servidor, algo não funcionou corretamente;
URL e URI
Passando pelos métodos e seguimentos de todo o funcionamento da rede com Arquitetura Cliente-Servidor, chegamos a um ponto denominado URL (Uniform Resource Locator ou Localizador Uniforme de Recursos), basicamente, é referencial do endereço virtual de uma página/diretório de informações localizada na World Wide Web (WWW). A URL é composta por fragmentos e funções específicas dando sequência formada a um protocolo de domínio e extensão redirecionada a uma referência de um subdiretório.
Já a URN (Uniform Resource Name) caracterizasse como o um recurso único e persistente da Web, não necessariamente, informando a localização exata dentro da Internet, como por exemplo, “www.livros.com/autor/livro.html”.
Enquanto a URL é um “Locator” dentro da páginação Web e a URN é um nome de identificação desse diretório, a URI (Uniforme Resource Identifier) é um identificador, ou seja, como uma URL também identifica, podemos dizer que ela está totalmente anexada e defini-se como um subconjunto das URI’s. Para diferenciarmos esses três segmentos, verificamos se o endereço do diretório, possui algum protocolo de acesso ou recurso e fragmento especificado da localização, sendo assim, denominando uma URI, por exemplo, “https://www.livros.com/autor/livro.html#pagina12”.
Figura 1I — Relação entre URN, URI e URL
Fonte: thiago.avila, 2018. Disponível em: https://i.stack.imgur.com/mcTKf.jpg
Considerações Finais
Considerando todas as informações dispostas nesse relatório, podemos concluir que a utilização da Arquitetura Cliente-Servidor e seus fundamentos são de extrema importância para navegações por diretórios disponibilizados dentro da World Wide Web, assim, facilitando o surf e o tornando mais seguro. Todos os métodos e funcionalidades pré-dispostas pela arquitetura tem sua notabilidade e dividem espaço nesse grande sistema.
Referências Bibliográficas
NAVES, P. Lagos andinos dão banho de beleza. Folha de S. Paulo, São Paulo, 28 jun. 1999. Folha Turismo, Caderno 8, p. 13.
(AMARAL,1993) Amaral, W. H. “Arquitetura Cliente/Servidor Orientada a Objeto” Tese de Mestrado, IME, 1993.
GOLDSTAR, Milton “Fundamentos da Arquitetura Cliente/Servidor”. https://pdfcoffee.com/fundamentos-da-arquitetura-cliente-servidor-pdf-free.html, 2005.
BECKENKAMP, Marcus, “API Rest e os verbos HTTP”. https://blog.mbeck.com.br/api-rest-e-os-verbos-http-46e189085e21, 13 nov. 2016.
FERREIRA, Gabriel, “Os métodos HTTP: quais são e pra que servem”. http://gabsferreira.com/os-metodos-http-e-a-diferenca-entre-eles/, 24 jul. 2015.
NAYAN, Kamal, “HTTP status code with explanation”. https://careerguroo.blogspot.com/2015/10/http-status-codes-with-explanation.html, 12 out 2015.
DUTRA, Daniel, “O que é URL? Entenda o endereço de sites mobile e portais da internet”. https://www.techtudo.com.br/noticias/2020/02/o-que-e-url-entenda-o-endereco-de-sites-mobile-e-portais-da-internet.ghtml, 29 fev 2020.
ÁVILA, Thiago “Bons identificadores universais (URIs) para a publicação de Dados Abertos (Conectados) — parte 01”. http://areasdeintegracao.blogspot.com/2018/04/bons-identificadores-universais-uris.html, 09 abr 2018;
PISA, Pedro, “Qual a diferença entre HTTP e HTTPS?”. https://www.techtudo.com.br/artigos/noticia/2012/07/qual-a-diferenca-entre-http-e-https.html, 10 out 2010.
OLIVEIRA, William. “URL ou URI, qual a diferença?”. https://woliveiras.com.br/posts/url-uri-qual-diferenca/, 20 jan 2015.
LUG, André, “Qual a diferença entre URL, URI e URN”. https://igluonline.com/qual-diferenca-entre-url-uri-e-urn/, 12 fev 2017.
TEIXEIRA, Márcio Andrey, “Arquitetura Cliente/Servidor”, 2019.
FUTCHER, Wesley, “Arquitetura Cliente/Software”, 2021.
