Exemplos de problemas de escalabilidade em arquiteturas cliente servidor

Analise as afirmativas a seguir, sobre tecnologias e arquitetura da Internet.

I - Ao utilizar uma conexão segura (https) com um site, se um cliente não possuir uma identidade digital, tal como um e-CPF ou e-CNPJ, somente serão criptografados os dados enviados do cliente para o servidor. Nesta situação, o servidor não deve exibir dados sigilosos para o cliente, pelo fato de os mesmos estarem sujeitos à interceptação; esta é a principal razão pela qual alguns serviços na Internet só são disponibilizados para clientes que possuem identidade digital.

II - Os formatos de distribuição de informações e notícias (newsfeeds) RSS e ATOM, baseados em XML e inicialmente utilizados em blogs, têm sido adotados nos mais variados tipos de sites como alternativa a outras modalidades de distribuição de notícias tais como as listas de e-mails.

III - O uso de folhas de estilo CSS externas nas páginas de um site ou aplicação Internet, em alternativa à marcação com atributos nos tags HTML e XHTML, proporciona uma redução significativa da exigência de banda, melhorando a experiência do usuário e demandando menos recursos dos servidores do site.

IV - O termo Web 2.0, atualmente em evidência, se refere a um conjunto de novos padrões e recomendações do W3C, bem como a tecnologias de diversos fabricantes, que tornam possíveis a criação de aplicações para a Web Semântica (Semantic Web) conforme vislumbrado por Tim Berners-Lee, o “criador” da Web.

Estão corretas APENAS as afirmativas

A arquitetura cliente-servidor surgiu na Xerox PARC durante os anos 70, com a intenção de resolver problemas recorrentes de aplicações desktop, como performance, escalabilidade, compatibilidade, entre outras. Hoje em dia a grande maioria dos softwares utiliza dessa arquitetura e você está usufruindo de um software que utiliza essa arquitetura nesse exato momento.

E porque devo me informar sobre isso?

Levando em consideração que uma grande parte de tudo que você vê e usa hoje em dia em questão de software é feita em um arquitetura cliente-servidor, conhecer um pouco dela poderá agregar muito conhecimento útil pra você. Então vamos aos pontos básicos.

Rest

A sigla REST, em português, significa “Transferência de Estado Representacional”. Essa arquitetura tem o objetivo de definir características fundamentais para o desenvolvimento de aplicações Web, que só funciona da maneira como conhecemos graças a essas práticas.

A utilização da arquitetura REST, portanto, permite a comunicação entre aplicações. Ao abrir o navegador, ele estabelece uma conexão com o servidor de destino e envia uma requisição HTTP, com o endereço buscado. O servidor, então, interpreta a requisição, retornando com uma resposta HTTP ao navegador. Essa resposta pode ser completa, com representações em formato HTML, ou apresentar erro, afirmando que o recurso solicitado não foi encontrado.

Requisições e respostas

Requisições HTTP são mensagens enviadas pelo cliente para iniciar uma ação no servidor. Essas contêm três elementos, sendo eles: Um método HTTP; O alvo, geralmente uma URL; A versão HTTP. Também pode contém um cabeçalho e um corpo da requisição.

Respostas HTTP, são enviadas como reação a uma requisição HTTP, e essas contém as seguintes informações: A versão do protocolo; Um código de status; Um texto de status, uma descrição textual breve. Também podem conter um cabeçalho e um corpo da resposta.

Métodos HTTP

Existem 4 métodos principais para as requisições http, sendo eles GET, POST, PUT e DELETE, veremos abaixo para que serve e qual a característica de cada um deles:

Get: O método GET solicita a representação de um recurso específico. Requisições utilizando o método GET devem retornar apenas dados.

Post: O método POST é utilizado para submeter uma entidade a um recurso específico, frequentemente causando uma mudança no estado do recurso ou efeitos colaterais no servidor.

Put: O método PUT substitui todas as atuais representações do recurso de destino pela carga de dados da requisição.

Delete: O método DELETE remove um recurso específico.

STATUS

Os códigos de status estão presentes nas respostas HTTP e indicam se uma requisição HTTP foi corretamente concluída de acordo com o tipo de estado retornado. Os códigos retornados podem ser dos seguintes grupos:

URL

Url: Em português, Localizador de Recursos Universal e como o próprio nome diz, se refere ao local, o Host que você quer acessar determinado recurso. O objetivo da URL é associar um endereço remoto com um nome de recurso na Internet.

Urn: Em português, Nome de Recursos Universal é o nome do recurso que será acessado e também fará parte da URI.

Uri: Em português, Identificador de Recursos Universal, como diz o próprio nome, é o identificador do recurso. Pode ser uma imagem, uma página, etc, pois tudo o que está disponível na internet precisa de um identificador único para que não seja confundido.

PARAMS

Existem três tipos de parâmetros, dois deles comumente utilizados no método GET e um no método no POST.

1-Query Params (GET): Recebe os dados da requisição como parâmetro na URL, e pode conter um ou mais parâmetros, exemplo:

Aonde “?” define a entrada dos parâmetros, e os mesmos são definidos por “chave=valor” e separados por “&”.

2-Route Params (GET): Recebe os dados da requisição na rota, é usado normalmente para buscar algo específico, deletar ou atualizar usando um identificador único, exemplo:

Aonde os caminhos “/tgmarinho” e “/380327” vão ser usados pelo servidor como parâmetros para realizar alguma ação.

3-Body Params (POST e PUT):Recebe os dados da requisição no corpo da requisição, em um objeto em JSON, exemplo:

BODY

O Request Body, ou corpo da requisição, é onde geralmente enviamos dados que queremos gravar no servidor. É no corpo da requisição onde você envia dados de um formulário de cadastro em seu site, por exemplo.

HEADER

No Header, ou cabeçalho da requisição, enviamos algumas informações referentes àquela requisição, como informações do host, política de cookies, encoding, tipo de resposta aceita e cache.

MEDIA TYPE

Os Media types são os mecanismos para dizer ao cliente a variedade de documentos transmitidos: a extensão de um nome de arquivo não tem significado na web. Portanto, é importante que o servidor esteja configurado corretamente, de modo que o media type correto seja transmitido com cada documento. O Json é o media type majoritariamente utilizado na web, porém temos vários outros media types, como esses abaixo:

HTTP VS HTTPS

A tradução é a mesma do HTTP, porém, com um “S” a mais que resulta em uma palavrinha que faz toda a diferença: Protocolo de Transferência de Hipertexto Seguro. Esse protocolo é uma junção entre o HTTP com o SSL (Secure Sockets Layers, ou, na nossa língua, Protocolo de Camadas de Entradas e Saídas Seguras).

O protocolo SSL produz a criptografia da transmissão de dados entre a sua máquina e um servidor. Dessa forma, o HTTPS oferece o sigilo dos nossos dados no processo de comunicação entre um navegador e um servidor.

Conclusão

Agora, com essas informações, você já tem uma base de como funciona a arquitetura cliente-servidor, e com isso tem o que precisa para usar e se for de seu interesse, se aprofundar nessa arquitetura que é a base de grande maioria do que usamos nos dispositivos hoje em dia!

Quais os dois exemplos mais conhecidos de arquitetura cliente

São exemplos clássicos de aplicações que funcionam sobre a arquitetura cliente

Quais as características de uma rede com arquitetura cliente

Quando usar arquitetura cliente