Sao Parte2
Sao Parte2
Autores:
Diego Carvalho, Fernando
Pedrosa Lopes
Aula 10
30 de Abril de 2021
Sumário
Web Services..................................................................................................................................................2
5 – Especificação de Metadados............................................................................................................. 13
REST ............................................................................................................................................................ 25
Gabarito ...................................................................................................................................................... 55
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
1
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
WEB SERVICES
1 – Conceitos Básicos
Outra definição importante – citada por Heather Kreger – destaca que um Web Service é, na
verdade, uma interface que descreve uma coleção de operações que são acessíveis pela rede
através de mensagens XML padronizadas. Seu uso permite que plataformas heterogêneas de
software e hardware sejam integradas de forma transparente. Vejamos mais definições...
Web Service é a disponibilização de um serviço pela internet que pode ser acessado em qualquer
lugar. Clientes enviam requisições com informações bem definidas e recebem respostas que
podem ser síncronas ou assíncronas. Web Service é essencialmente a interoperabilidade entre
programas e aplicações – especialmente quando eles usam linguagens, ferramentas ou
plataformas diferentes.
Segundo a definição do Gartner, Web Services são componentes de software com baixo fator de
acoplamento, utilizado por meio de padrões de internet. Um Web Service representa uma
função/lógica de negócio ou um serviço que pode ser acessado por uma outra aplicação na
web, sobre redes públicas e, geralmente, disponibilizado por protocolos conhecidos.
A disponibilização de um serviço ocorre por meio de um contrato, que é uma interface que
disponibiliza suas funcionalidades, com uma infraestrutura leve e desacoplada de plataforma
que facilita a integração em diferentes tecnologias. Esta tecnologia possibilita que novas
aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em
plataformas diferentes sejam compatíveis.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
2
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Não, um cliente pode invocá-lo de forma síncrona ou assíncrona. Possibilitar chamadas assíncronas é a chave
para permitir sistemas fracamente acoplados.
Não, eles são baseados em XML (para representação e transporte de dados). Nesse último caso, ele elimina
qualquer dependência com rede e sistema operacional.
Eles são fracamente acoplados. A interface de um serviço web pode mudar durante o tempo sem comprometer
a habilidade do cliente de interagir com o serviço.
Sim, eles são independentes de plataforma, sistema operacional, arquitetura de processador, linguagem de
programação, entre outros.
Eles possuem granularidade grossa, provendo uma maneira natural de definir serviços que acessam a
quantidade correta de lógica de negócio.
Sommerville afirma que um Web Service é uma instância de uma noção mais geral de um serviço.
A plataforma de serviços web é definida através de uma série de padrões da indústria que são
suportados por toda a comunidade de fornecedores. Esta plataforma pode ser dividida em
duas gerações claramente identificáveis , cada uma associada com um conjunto de normas
e especificações:
1
O WS-I Basic Profile é um conjunto de especificações de serviços da Web não proprietários, juntamente com esclarecimentos e alterações a
essas especificações que promovem a interoperabilidade.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
3
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Uma das maiores lacunas de qualidade dos Web Services de Primeira Geração residia nas áreas
de segurança em nível de mensagem, transações entre serviços e mensageria confiável.
Surgiram, então, diversas extensões e especificações para fornecer um conjunto sofisticado
de componentes construídos sobre os Web Services de Primeira Geração – foram chamados
de WS-*.
O WS-* é composto atualmente por diversas especificações: Segurança (Ex: WS-Security, WS-
Trust, WS-Encryption, WS-SecureConversation); Políticas (Ex: WS-Policy, WS-
PolicyAssertions); Processos de Negócio (Ex: WS-CDL, WS-BPEL); entre outros. Galera, são
dezenas de especificações de diversos tipos – não vale a pena ver todos, vamos ver por
curiosidade apenas alguns deles:
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
4
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Nessa aula, vamos nos ater aos Web Services de Primeira Geração! Utilizar serviços através da
rota dos Web Services basicamente envolve três categorias de participantes: Provedor de
Serviço, Solicitante do Serviço e Agente de Serviço (em inglês, Service Provider, Service
Requester e Service Broker) – basta lembrar do modelo arquitetônico triangular (Find-Bind-
Execute).
Um provedor de serviços seria, por exemplo, uma indústria, negócio ou empresa, capaz de criar
e fornecer serviços baseados em software. Do mesmo modo, um solicitante de serviços seria
uma empresa ou um negócio que gostaria de usar o serviço. Por outro lado, o agente seria um
lugar, entidade ou sistema, que ajuda o solicitante de serviços a descobrir o provedor de serviços.
Sabemos que Web Services são sistemas embasados na web que oferecem serviços gerais para
aplicações remotas, não requerendo interações imediatas de usuários finais – em geral a
interação é máquina-máquina ou aplicação-aplicação. Além da definição, é bom saber a
descrição dos três padrões fundamentais que possibilitam as comunicações, isso sozinho
resolve uma pancada de questões:
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
5
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
No entanto, vocês verão algumas vezes as provas tratarem serviços apenas aqueles que
implementam SOAP, UDDI e WSDL. Não sejam muito rigorosos com isso...
Trata-se de uma das formas de comunicação para encapsular dados transferidos no formato XML para Web
Services.
Trata-se de um formato, baseado em XML, para intercâmbio de mensagens – é utilizado para realizar o
encapsulamento e o transporte de dados.
Trata-se de um formato para envio e recebimento de mensagens independentemente de plataforma e
tecnologia.
Trata-se de um protocolo baseado em XML que define uma organização para a troca estruturada de dados
entre Web Services.
Um dos motivos que tornam os Web Services atrativos é o fato de estes serem baseados em
tecnologias padrão, em particular XML e HTTP. Eles são comumente utilizados para
disponibilizar serviços interativos na web, podendo ser acessados por outras aplicações. O
SOAP é o protocolo mais comum para troca de mensagens, já que é escrito em XML e
transportado, via de regra, por HTTP.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
6
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
(HTTP). Pessoal, é obrigatório utilizar esse protocolo de transporte? Não! Pode-se usar qualquer
um, no entanto esse é o mais comumente utilizado no mercado atualmente.
Entre outras utilizações, SOAP foi desenhado para encapsular e transportar Chamadas RPC
e, para isto, utiliza-se dos recursos e flexibilidade do XML, sob HTTP. Por meio do RPC, pode-
se acessar os serviços de um objeto localizado em um outro ponto da rede, através de uma
chamada local a este objeto. Cada chamada ou requisição exige uma resposta.
Os blocos de cabeçalhos SOAP podem ser processados por nós intermediários SOAP e pelo nó
receptor SOAP final. No entanto, em um aplicativo real, nem sempre cada nó processa cada
bloco de cabeçalhos. Cada nó geralmente é projetado para processar determinados blocos de
cabeçalhos e cada bloco de cabeçalhos é processado por nós específicos.
Nós não dissemos ainda se SOAP é um protocolo Stateful ou Stateless, mas antes de
descobrir, temos que saber o que são esses conceitos. Stateful significa que o servidor
armazena informações sobre o cliente e as utiliza em diversas requisições. Stateless é justamente
o contrário, i.e., o estado do serviço não é persistido entre requisições subsequentes. O HTTP e
o SOAP, por default, são protocolos stateless. O SOAP, definido pela W3C, consiste basicamente
dos elementos descritos abaixo:
▪ Envelope (Envolope):
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
7
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
▪ Cabeçalho (Header):
▪ Corpo (Body):
Ele contém o payload, i.e., a mensagem SOAP. Trata-se de um elemento obrigatório que é capaz
de empacotar chamadas RPC, reportar erros, enviar operações UDDI, entre outros. O elemento
Body pode conter um elemento opcional Fault, usado para carregar mensagens de status e
mensagens de erros retornadas pelos nós ao processarem a mensagem. É obrigatório! Vejam
abaixo em negrito cada um desses elementos: Envelope, Header e Body.
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<soap:Header>
<m:Trans xmlns:m="https://www.w3schools.com/transaction/"
soap:mustUnderstand="1">234
</m:Trans>
</soap:Header>
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
Trata-se de uma linguagem de descrição de Web Services, escrita em XML, para descrever serviços web,
especificar as formas de acesso, as operações e os métodos disponíveis.
Trata-se de uma linguagem para descrever serviços de rede como endpoints (ou portas) que operam em
mensagens que contêm informações orientadas à documento/procedimento.
Trata-se efetivamente de especificação que define como descrever serviços web em uma gramática XML.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
8
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Vocês já pensaram de que forma um cliente de um Web Service sabe qual formato dos métodos a
serem chamados? Quais os parâmetros que devem ser passados? Como se deve processar uma
requisição específica? Para responder essas questões, criou-se uma linguagem para padronizar
as descrições das funcionalidades oferecidas por um Web Service.
Essa linguagem, baseada em XML, é utilizada para descrever um Web Service e deve,
portanto, definir todas as suas interfaces, operações, métodos, esquemas de codificação, portas
de comunicação, protocolos, formatos de mensagens, entre outros, neste documento. Um
documento WSDL define um XML Schema (XSD) para descrever um Web Service.
Tão logo o cliente tenha acesso à descrição do serviço a ser utilizado, a implementação do Web
Service pode ser feita em qualquer linguagem de programação. Normalmente são utilizadas
linguagens construídas para interação com a Web, como Java Servlets ou ASP, que, em seguida,
chamam um outro programa ou objeto.
Quando o cliente deseja enviar uma mensagem para um Web Service, ele obtém a descrição do
serviço (em geral, por meio da localização do documento WSDL no UDDI), e em seguida constrói
a mensagem, passando os tipos de dados de acordo com a definição encontrada no
documento. Em seguida, a mensagem é enviada para o endereço onde o serviço está localizado,
a fim de que possa ser processada.
O Web Service, quando recebe esta mensagem, valida-a conforme as informações contidas
no documento WSDL. A partir daí, o serviço remoto sabe como tratar e processar a mensagem
e como responder ao cliente. O WSDL possui um elemento-raiz do documento chamado
Description, que se trata de um contêiner de duas categorias de alto nível: WSDL 2.0 e Type
System.
O WSDL 2.0 é formado pelos componentes Interface, Binding e Service; já o Type System é
formado pelos componentes Element Declaration e Type Definition. O Element Declarations
é um conjunto de declarações de elementos, como definido por um XML Schema. Já o Type
Definitions é um conjunto de definições de tipos de dados – ele é obrigatório (Não confundam
com o elemento <types>).
Esse componente descreve sequências de mensagens que um serviço envia e/ou recebe. Ele o
faz agrupando mensagens relacionadas em operações (é o antigo <portType>). Interface →
Operações → Mensagens
Esse componente descreve o formato de mensagens e protocolos de transmissão que podem
ser usados para definir um endpoint. Ele define detalhes de implementação necessários para
acessar um serviço.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
9
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
De acordo com George Coulouris, os documentos WSDL completos podem ser acessados por
meio de seus URIs por clientes e servidores, direta ou indiretamente, por intermédio de um
serviço de diretório como o UDDI. Estão disponíveis ferramentas para gerar definições WSDL
a partir de informações fornecidas por meio de uma interface gráfica com o usuário.
Elas fazem isso ao eliminar a necessidade de envolvimento dos usuários com os detalhes
complexos e com a estrutura do WSDL. As definições WSDL também podem ser geradas a partir
de definições de interface escritas em outras linguagens, como JAX-RPC. Ele não define
características não-funcionais do serviço (Ex: tempo de resposta, escalabilidade, segurança).
Ademais, define quatro tipos de operações:
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
10
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
A operação pode receber uma mensagem, mas não retornará uma resposta.
A operação pode receber uma requisição e retornará uma resposta.
A operação pode enviar uma requisição e esperará por uma resposta.
A operação pode enviar uma mensagem, mas não esperará por uma resposta.
Trata-se de um serviço de diretório, baseado em XML, em que é possível registrar e localizar Web Services.
Trata-se de uma especificação técnica que tem como objetivo descrever, descobrir e integrar Web Services.
Quando se constrói um Web Service, ele deve ser disponibilizado em algum lugar para que seja
acessível por diversas aplicações-cliente. O UDDI é uma especificação técnica para descrever,
descobrir e integrar Web Services (alguns o chamam de protocolo também). Ele contém
informações genéricas sobre a organização que o detém e informações básicas sobre os serviços.
Vocês entenderam?
O UDDI descobre serviços por meio de registries, que são repositórios logicamente centralizados
e fisicamente distribuídos que contêm documentos descritores dos dados do negócio. As
informações capturadas no contexto do UDDI são classificadas em três categorias principais:
Páginas Brancas, Páginas Verdes ou Páginas Amarelas, como mostra a imagem abaixo com
seus respectivos exemplos:
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
11
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
As Páginas Verdes contêm informações técnicas sobre como acessar um Web Service. Elas
são utilizadas para indicar os serviços oferecidos por cada negócio, incluindo todas as
informações técnicas envolvidas na interação com o serviço. Em geral, essas informações
incluem um ponteiro para uma especificação externa e um endereço para invocar o serviço.
Pessoal, não confundam uma coisa: WSDL não fica efetivamente no UDDI, mas lá existem
referências para ele! Ok? A UDDI 3.0.2 (versão mais recente) possui um Modelo de Informação
Estruturada: Core Data Structure. Ele é composto por uma estrutura hierárquica formada por:
Entidade de Negócio (Business Entity), Serviço de Negócio (Business Service), Template de
Ligação (Binding Template) e tModel.
O Business Entity representa o provedor de Web Services. Essa estrutura contém informações
sobre a organização, incluindo informações de contato, categorias de indústria, identificadores
de negócio e uma lista de serviços fornecidos. O Business Service representa um Web Service
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
12
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
individual fornecido por uma entidade de negócio – define tipo de serviço, conexão,
categorias, entre outros.
O Binding Template é um conjunto de descrições técnicas dos Web Services representados por
uma estrutura de serviços de negócio – ele indica, por exemplo, como se conecta ao serviço. Por
fim, o tModel representa um modelo técnico, i.e., uma maneira de descrever os vários
negócios, serviços, estruturas de template e informações externas (Ex: WSDL) armazenados
dentro de um Registro UDDI.
5 – Especificação de Metadados
Recentemente, com o surgimento dos periódicos eletrônicos, esse problema ainda persiste,
pois muitos só oferecem acesso aos artigos mediante pagamento. A cada dia, surgem
bibliotecas digitais e bases de dados públicas que constituem importante fonte de informação
para pesquisadores. O problema é o tempo que se gasta para reunir informações relevantes a um
dado assunto de pesquisa.
Seja visitando diversos portais de bibliotecas virtuais, seja utilizando a busca convencional
oferecida por sites como Google, Bing, entre outros. A pesquisa através de portais de busca
tradicionais é imprecisa e atinge apenas as páginas HTML, ignorando as bases de dados que se
encontram por trás de algumas destas páginas.
Por outro lado, ao tentar divulgar seus trabalhos através dos periódicos, em busca do impacto de
suas pesquisas, os pesquisadores esbarram em um processo burocrático e demorado, em que,
desde a submissão até a publicação, devido à lenta arbitragem que por vezes ocorre, pode
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
13
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
haver um intervalo de tempo tão longo que os efeitos daquela pesquisa já não tenham valor
quando de sua publicação.
Com a evolução da Internet, várias bibliotecas digitais começaram a surgir – algumas com a
finalidade de expor a produção de teses e dissertações das grandes universidades. Tudo isso
resultou em um grande avanço, em que informações científicas e acadêmicas já poderiam ser
obtidas livremente pela Internet, e disponibilizadas através da publicação nas páginas de seus
autores.
Com os recursos oferecidos pela iniciativa, é possível melhorar significativamente a precisão das
consultas eletrônicas e reduzir o tempo de procura, graças ao compartilhamento de informações
(metadados) entre os participantes da iniciativa. A interoperabilidade entre bases de dados
tem o objetivo de promover o acesso simultâneo aos dados contidos nestes repositórios de
forma a maximizar a pesquisa.
O protocolo OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting) vem se
consolidando como a base para a interoperabilidade entre bibliotecas e repositórios digitais
acadêmicos e científicos no mundo todo. Através do OAI-PMH, é possível proporcionar
visibilidade e integração de informações (metadados), com custos acessíveis à realidade de
países em desenvolvimento, como o Brasil.
Então, vamos lá! Em 1999, surgiu a Open Archives Initiative (OAI), que buscava desenvolver e
promover soluções de interoperabilidade que facilitassem uma disseminação eficiente de
conteúdo. Para tal, foi criado um protocolo aberto, independente de conteúdo, chamado
OAI-PMH que faz com que participantes da iniciativa possam compartilhar seus metadados.
Lembrando que metadados são dados sobre dados, isto é, informações que descrevem
informações dos registros dos repositórios (similar a um dicionário) – no caso, documentos
eletrônicos. Para tal, ele segue um padrão que contém, entre outros, título, autor, resumo,
palavras-chaves, etc. Os participantes da Iniciativa são divididos em Provedores de Dados (DP) e
Provedores de Serviços (SP).
O Harvesting (ou Colheita Automática de Metadados) é uma técnica ou processo unilateral para
extrair metadados de repositórios individuais e colocá-los em um catálogo central. Esse
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
14
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Provedores de Serviços (SP) realizam periodicamente uma busca a Provedores de Dados (DP) –
registrados em uma lista na OAI – para colher metadados para exibição sob a forma de consultas
efetuadas pelos usuários. Essa busca pode ser geral ou baseada em alguns critérios, tais como
Date-Based (baseados em data) ou Set-Based (baseados em conjuntos).
Na Federation, o usuário faz uma requisição síncrona a um repositório central (representado por
uma Biblioteca Digital) e espera a resposta. O repositório faz diversas requisições a outros
repositórios remotos e as respostas retornam para o repositório central onde são
consolidadas e devolvidas para o usuário. Bacana? Agora vamos ver como funciona a outra
abordagem.
Como a busca é executada em uma cópia local dos metadados, resultados podem ser
retornados com baixíssima latência. Além disso, como o harvesting é feito periodicamente,
mesmo que qualquer biblioteca esteja indisponível, ainda é possível buscar seus metadados.
Quanto à especificação de web services, existem diversas categorias de especificações
diferentes.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
15
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Estas especificações estão em diferentes graus de maturidade e são mantidas ou apoiadas por
vários órgãos e entidades de normatização. Esta variedade de especificações é a estrutura básica
de web services estabelecido pelos padrões de primeira geração representada por WSDL, SOAP
e UDDI. As especificações podem se complementar, se sobrepor e competir umas com as
outras.
Permite que web services utilizem XML para advertir sobre suas políticas (de
qualidade, segurança, etc) e também para que clientes possam especificar suas
políticas.
Especifica como integridade e confidencialidade podem ser aplicadas em
mensagens e permitir a comunicação com vários formatos de token de segurança.
6 – WS-Security (WSS)
Vamos lá! Pensem comigo: eu falei alguma vez sobre segurança de Web Services? Não, porque o
Protocolo SOAP não prevê a proteção de mensagens, deixando essa tarefa para
especificações estendidas! Ora, mas SOAP é um protocolo que roda (na maioria dos casos2) sobre
o protocolo HTTP! É verdade, você tem razão! Ele é utilizado para troca de mensagens entre dois
nós.
2
Eventualmente, pode rodar sobre outros protocolos (tais como: JMS e SMTP).
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
16
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
a mensagem se mantém confidencial. No entanto, nem sempre se utiliza esse protocolo; além
disso, ele possui diversas limitações quando a mensagem passa por diversos pontos.
Você pode me perguntar: Professor, por que não é utilizado o Protocolo HTTPS para garantir mais
segurança para Web Services? Faz muito sentido a sua pergunta! Ora, o Protocolo SSL/TLS é
capaz de fornecer diversos mecanismos de segurança. No entanto, ele funciona bem para
fornecer segurança em comunicação ponto-a-ponto, e nós precisamos de segurança em
comunicação fim-a-fim. Bacana?
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
17
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
7 – Protocolo HTTP
A primeira coisa que vocês podem me perguntar é: professor, isso não é uma disciplina de Redes
de Computadores? Sim, você está certo! No entanto, nosso intuito aqui é dar uma visão muito
mais restrita, sob a perspectiva de desenvolvimento de sistemas. O Protocolo HTTP (HyperText
Transfer Protocol) é um protocolo de comunicação utilizado para transferência de
hipertextos.
O que seria um hipertexto? Trata-se de um texto que pode ser integrado a diversas outras
formas de informação, como imagens, sons e outras mídias, acessíveis por meio de
hiperlinks. Dito isso, o que importa de fato para o desenvolvimento de sistemas? Bem, esse
protocolo define oito métodos (ou verbos), que nós veremos em mais detalhes mais à frente.
Embora tenha sido projetado para utilização na Web, o protocolo foi criado de modo mais geral
que o necessário, visando às futuras aplicações orientadas a objetos. Por essa razão, são aceitas
essas operações chamadas Métodos, diferentes da simples solicitação de uma página da
web. Essa generalidade permitiu que o Protocolo SOAP viesse a existir.
Cada solicitação consiste em uma ou mais linhas de texto ASCII, sendo a primeira palavra da
primeira linha o nome do método solicitado – os métodos internos estão listados abaixo. Para
acessar objetos gerais, também podem estar disponíveis métodos adicionais específicos de
objetos. Os nomes diferenciam letras maiúsculas de minúsculas; portanto, GET é um método
válido, mas get não é.
Esse método solicita ao servidor que envie uma página (ou um objeto, no caso mais genérico; na
prática, apenas um arquivo). A grande maioria das solicitações a servidores da web tem a forma de
métodos GET. No CRUD, ele seria o R(ead).
Esse método solicita apenas o cabeçalho da mensagem, sem a página propriamente dita. Esse
método pode ser usado para se obter a data da última modificação feita na página, para reunir
informações destinadas à indexação, ou apenas para testar a validade de uma URL.
Esse método é o inverso do GET, i.e., em vez de ler, ele grava a página. Esse método possibilita a
criação de um conjunto de páginas da web em um servidor remoto – o corpo da solicitação contém
a página. No CRUD, ele seria o U(pdate).
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
18
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Esse método é semelhante ao PUT – porque também transporta um URL –, no entanto, em vez de
substituir os dados existentes, os novos dados são "anexados" a ele, em um sentido mais genérico.
No CRUD, ele seria o C(reate).
Esse método faz exatamente isso: exclui uma página. A exemplo do PUT, a permissão e a
autenticação têm papel fundamental. Não há garantia de que DELETE seja bem-sucedida, pois –
mesmo que o Servidor HTTP Remoto esteja pronto para excluir a página – o arquivo subjacente
pode ter um modo que impeça o Servidor HTTP de modificá-lo ou excluí-lo. No CRUD, ele seria o
D(elete).
Esse método serve para depuração. Ele instrui o servidor a enviar de volta a solicitação. Ele é útil
quando as solicitações não estão sendo processadas corretamente e o cliente deseja saber qual
solicitação o servidor, de fato, recebeu.
Esse método não é utilizado atualmente – ele é reservado para uso futuro.
Esse método fornece um meio para que o cliente consulte o servidor sobre suas propriedades ou
sobre as propriedades de um arquivo específico.
Esse método é bastante parecido com o PUT. No entanto, ele é utilizado para atualizar registros
parcialmente, enquanto o PUT atualiza o registro como um todo.
Galera, se chegar uma URL para o Servidor HTTP requisitando um serviço, o que ele fará? Ora, isso
depende do método utilizado! Quando chega a requisição, o servidor sempre implementará ao
menos dois métodos: HEAD e GET. Nosso interesse é no Método GET: ele é responsável por
solicitar recursos a um Servidor HTTP! Que recurso, professor? Pode ser qualquer coisa:
arquivos, scripts, etc.
Imagine que você faça a requisição acima! O que vem após a interrogação indica o início dos
dados passados através da URL, i.e., pelo Método GET! Observem o seguinte: eu requisitei
algum dado (arquivo, imagem, sons, etc) e para tal eu enviei algumas informações (aquilo após
a interrogação)! Vocês podem me perguntar: Professor, as informações são visíveis na URL
mesmo? Pois é, sim!
Vocês percebem como isso é perigoso? Viram que a minha senha está visível? Ela fica visível na URL!
Deiltel já dizia: Uma solicitação get não deve ser utilizada para enviar dados sigilosos porque
os dados do formulário são colocados em uma string de consulta que é acrescentada ao URL
do navegador como texto simples e pode ser interceptada. Lembrando que, por padrão, é
utilizado o GET.
Para resolver esse problema, eu posso utilizar o POST. Ele funciona de modo bastante similar,
entretanto os dados são colocados no corpo da requisição e não aparece diretamente na URL!
Melhor, não? Só isso? Não! GET é utilizado para recuperar informações (em geral, poucas); POST
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
19
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
é utilizado para enviar informações (em geral, muitas – por meio de formulário). Vamos ver
outras diferenças:
Pode ser adicionado aos favoritos. Não pode ser adicionado aos favoritos.
Agora, vamos examinar como as conexões seguras podem ser alcançadas. Quando a web
repentinamente chegou ao público, ela foi usada no início apenas para distribuir páginas
estáticas, mas – em pouco tempo – algumas empresas tiveram a ideia de usá-la para transações
financeiras, como a compra de mercadorias por cartões de crédito; transações bancárias e
mercado de capitais eletrônico.
Essas aplicações criaram uma demanda por conexões seguras. Em 1995, a Netscape, que então
dominava o mercado de fabricantes de navegadores, respondeu introduzindo um pacote de
segurança chamado SSL (Secure Sockets Layer) para atender a essa demanda. Esse software
e seu protocolo agora também são amplamente utilizados por diversos navegadores.
A SSL constrói uma conexão segura entre dois soquetes, incluindo: negociação de parâmetros
entre cliente e servidor; autenticação mútua de cliente e servidor; comunicação secreta; e
proteção da integridade dos dados. Efetivamente, trata-se de uma nova camada colocada
entre a camada de aplicação e a camada de transporte, aceitando solicitações do navegador
e enviando-as para o servidor.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
20
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Por fim, vamos falar rapidamente sobre Idempotência. Méquié, professor? Um Método HTTP
idempotente é aquele que pode ser chamado muitas vezes sem resultados diferentes. Não
importa se o método for chamado apenas uma vez, ou dez vezes mais, o resultado deve ser o
mesmo! Mais uma vez, isso se aplica apenas ao resultado e não ao próprio recurso. Vamos ver
um exemplo bastante simples:
a = 4;
Eu posso executar esse comando 800 vezes e eu vou obter sempre o mesmo resultado – ele é
idempotente. Agora vejam o exemplo abaixo:
a++;
O resultado será sempre diferente: 5, 6, 7, etc – ele não é idempotente. Dito isso, nós
podemos imaginar quais Métodos HTTP são idempotentes:
SIM
NÃO
SIM
SIM
SIM
SIM
NÃO
Ué, professor! Por que o POST não é idempotente? Porque cada vez que eu insiro algum dado em
uma tabela, por exemplo, por meio do POST, eu aumento o tamanho dessa tabela, logo o
resultado não é sempre o mesmo. E quando o resultado não é sempre o mesmo, nós sabemos
que não se trata de um método o quê? Idempotente! Certinho?
SIM
NÃO
NÃO
NÃO
SIM
SIM
NÃO
A tabelinha acima mostra também os métodos que são seguros. O que é segurança nesse
contexto, galera? Um método é considerado seguro se ele não modifica os recursos. Logo,
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
21
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
POST, PUT, DELETE e PATCH são inseguros, visto que os recursos são modificados após a
execução desses métodos. Já GET, HEAD e OPTIONS são seguros, visto que não modificam os
recursos.
Sabemos que HTTP é um protocolo Stateless! Isso quer dizer que o Servidor Web, somente com
o que oferece nativamente o HTTP, não sabe se sua requisição de agora e outra daqui a 10s são
pertencentes a mesma sessão ou não. Então, como sempre que entro no Facebook, ele sabe meu
nome? Quando entro num site e parece que estava logado, mesmo eu tendo acabado de ligar o
computador?
Uma forma de trabalhar com dados stateful é justamente utilizar informações armazenadas em
cookies. O cookie HTTP, também chamado de cookie web, cookie de Internet, cookie de
navegador ou, simplesmente: cookie; é um pequeno conjunto de dados enviado por um
servidor web e armazenado no computador do usuário pelo navegador, enquanto ele está
navegando.
A especificação de como os cookies funcionam foi publicada como a RFC 6265 e será nossa
grande fonte de informações (somente aquilo que é cobrado nos concursos, obviamente). Os
cookies foram criados como um mecanismo para sites se lembrarem de informações dentro
de uma sessão (Ex: como os itens num carrinho de compras).
Quer outro exemplo? Para armazenar as atividades de navegação do usuário (incluindo cliques
num determinado botão, ação de logar, quais páginas visitou no passado). Os dados
informados em preenchimento de formulários (endereços, senhas e até cartões de crédito)
também podem ser armazenados em cookies para utilização do servidor web.
O Servidor Web utiliza o campo Set-Cookie do cabeçalho HTTP para passar pares de
nome/valor com metadados associados (chamados cookies) para um User Agent
(navegadores em desktops, em celulares, etc). Quando o usuário envia requisições
subsequentes para o servidor, o seu User Agent utiliza os metadados e outras informações para
avaliar se envia ou não os pares nome/valor de volta ao servidor.
Por meio do campo Set-Cookie do cabeçalho um servidor pode enviar ao user agent uma
pequena string dentro da resposta HTTP para identificar, por exemplo, um identificador de
sessão, ou SID. Para identificar as próximas requisições como sendo daquela sessão, o usuário
(user agent) envia o SID com o mesmo identificador. Por exemplo:
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
22
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Set-Cookie: SID=31d4d96e407aad42
Cookie: SID=31d4d96e407aad42
O servidor pode alterar o escopo do cookie para informar que o usuário pode enviar a resposta à
solicitação de cookie para todos as URLs de um certo subdomínio, ex:
Cookie: SID=31d4d96e407aad42
O servidor pode armazenas inúmeros cookies na máquina do usuário. Ele pode, por exemplo,
armazenar um identificador de sessão bem como o idioma do usuário.
Para isso, basta que envie dois campos Set-Cookie no cabeçalho HTTP. Percebam que o
cabeçalho define dois cookies, um com um identificador de sessão e outro que define o idioma e
o domínio para resposta do User Agent. O atributo Secure limita o escopo do cookie para
somente trafegar em canais seguros (o mais comum é usar o HTTP sobre Transport Layer
Security - TLS).
Apesar do atributo, é possível que um hacker ativo na rede corrompa a integridade do cookie. Já
o atributo HttpOnly limita o escopo do cookie para requisições HTTP somente. Caso o
servidor queira que o User Agent armazene o cookie por mais de uma sessão, ele pode especificar
uma data de expiração a partir do atributo Expires. Entendido isso?
Nada impede que o usuário delete o cookie antes da data de expiração manualmente ou pelo
descarte do navegador por chegar a um limite de cookies:
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
23
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Finalmente, para remover um cookie, o servidor deve enviar o Set-Cookie com uma data de
expiração no passado. A remoção só funciona se os atributos Path e Domain forem iguais aos
definidos no momento da criação do cookie.
Cookie: SID=31d4d96e407aad42
Além do atributo Expires, existe o atributo Max-Age que indica quanto tempo deve durar a
vida de um cookie. Sim, você pode controlar isso! Claro que, mais uma vez, isso depende da
“boa vontade” do User Agent de manter esse cookie até o fim. Nem todos os User Agents
suportam esse atributo e, nesse caso, simplesmente a ignoram. Tranquilo?
Vocês já devem ter visto bastante os navegadores web que perguntam se você deseja salvar os
cookies, que podem ser utilizados de forma invasiva por hackers, sim? Pois é, o servidor envia o
cabeçalho Set-Cookie, mas o usuário pode simplesmente ignorar! Sai fora que não quero meus
dados de navegação indo para seu servidor, e minha privacidade?! ;)
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
24
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
REST
1 – Conceitos Básicos
O SOA tem seu nome utilizado de maneira bastante errada, eu imagino que isso ocorra devido
ao fato de que muitos ainda fazem uma forte associação entre o conceito abstrato e alto nível de
SOA e a tecnologia de Web Services, que – inicialmente – tornou-se a maneira mais popular de
implementá-lo. Percebam que muitas discussões na internet falam sobre "REST vs SOA"3.
Ora, isso é como comparar maçãs com laranjas! Por isso, vamos dar um passo atrás e olhar
para a motivação original do SOA. Em praticamente qualquer empresa, muitos sistemas
individuais compõem o cenário completo de TI. Eles rodam em diversas tecnologias e foram
construídos usando ferramentas diferentes. Alguns foram adquiridos de fornecedores
comerciais, outros foram desenvolvidos, etc.
Depois de um curto período de tempo, você vai querer conectá-los, porque obviamente há
muito valor em fazê-lo. É possível fazer isso de uma maneira ponto-a-ponto: a exportação de
alguns dados aqui, periodicamente importá-lo de lá; por meio de arquivos; bancos de dados
compartilhados; ou soluções de integração individuais. Essas soluções, em geral, levarão a uma
situação frágil e incontrolável.
Utilizar um middleware de integração centralizado não é uma boa solução (será um gargalo),
embora – em primeiro lugar - possa parecer tentador! Você se torna dependente do único
fornecedor, que pode ser comprado por outra organização, sair do negócio, ou tornar-se legado
após mesclar com um concorrente que tenha comprado outro produto deste tipo mais
recentemente.
Então, o que você faz em vez disso? Você trata o problema de uma forma razoável. Como?
Reduzindo a quantidade de esforço para integrar os sistemas individuais, limitando a quantidade
de diferentes tecnologias utilizadas na camada de interface, escolhendo uma boa interface de
abstração, e – principalmente - modularizando as grandes aplicações em pequenos pedaços.
E essa é a essência da arquitetura orientada a serviços: uma arquitetura de software que não é
aplicada a um sistema individual, mas a um conjunto de sistemas dentro de uma
organização; concentrando-se em interfaces e, não, em implementação; padronizando o que
for necessário para garantir uma comunicação fácil e um reúso casual, mas nada mais.
Bacana! Essa é a motivação do SOA! Nós vimos que é possível comunicar sistemas diferentes
de várias formas e que uma delas é por meio serviços. Você quer dizer Web Service, professor?
3
Uma comparação mais adequada seria entre os estilos: REST x WS-*.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
25
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Bem, não necessariamente! Você pode implementar serviços com outras tecnologias (Ex:
CORBA ou DCOM), mas – de fato – a implementação mais comum é por meio de Web Services.
É importante que vocês saibam que REST é diferente de SOA! Qual a diferença? SOA é uma
arquitetura e REST é um estilo arquitetural 4. E tem diferença, professor? Sim, meus caros! A
arquitetura é neutra; já o estilo arquitetural, não. REST pode ser visto como o fornecimento de
uma implementação de serviços com requisitos de design específicos para determinadas
tecnologias e arquiteturas.
O SOA pode ser visto como o fornecimento de uma abordagem tecnologicamente neutra ao
design de serviços que pode ser aplicada a um grande número de implementações, incluindo
Web Services e REST. Cada implementação possui sua coleção única de tecnologias, requisitos
de design, e artefatos/propriedades arquiteturais, algumas das quais suportam diferentes
princípios em diferentes níveis.
Grosso modo, podemos comparar com a arte! Se procurarmos a definição de arquitetura, vamos
encontrar: “(...) refere-se tanto ao processo quanto ao produto de projetar e edificar o ambiente
habitado pelo ser humano”. Percebam que não há limitações ou restrições, trata-se de um
conceito bastante amplo. E o que ocorre se procurarmos a definição de estilo arquitetural?
4
Muitas questões ainda afirmam que REST é uma arquitetura! Apesar de não estar completamente correto, não marquem errado apenas por
conta disso.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
26
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Responsabilidades devem ser separadas entre clientes e servidores. Isso permite que os
componentes do cliente e do servidor evoluam de forma independente e, por sua vez,
permite que o sistema seja escalável. Em outras palavras, busca-se separar a arquitetura e
responsabilidades em dois ambientes.
Dessa forma, o cliente não se preocupa com tarefas do tipo: comunicação com banco de
dados, gerenciamento de cache, log, etc; e o contrário também é válido, o servidor não se
preocupa com tarefas como: interface, experiência do usuário, etc. Permitindo, assim, a
evolução independente das duas arquiteturas.
A comunicação entre cliente e servidor deve ser stateless. O servidor não precisa lembrar o
estado do cliente. Em vez disso, os clientes devem incluir todas as informações necessárias
na requisição para que o servidor possa entendê-la e processá-la.
Em outras palavras, um mesmo cliente pode mandar várias requisições para o servidor,
porém cada uma delas deve ser independente, ou seja, toda requisição deve conter todas
as informações necessárias para que o servidor consiga entendê-la e processá-la
adequadamente (qualquer informação de estado deve ficar no cliente).
Múltiplas camadas hierárquicas, como gateways, firewalls e proxies podem existir entre o
cliente e o servidor. As camadas podem ser adicionadas, modificadas, reordenadas, ou
removidas de forma transparente para melhorar a escalabilidade – deve ser fácil, então,
manipular camadas (tornando o sistema mais flexível).
O cliente nunca deve chamar diretamente o servidor da aplicação sem antes passar por um
intermediador (Ex: Balanceador de Carga). Isso garante que o cliente se preocupe apenas
com a comunicação com o intermediador e o intermediador fique responsável por distribuir
as requisições aos servidores.
Isso significa que, quando um primeiro cliente solicita um determinado recurso ao servidor,
esse processa a requisição e o cliente a armazena temporariamente em cache. Quando
houver uma nova requisição, a resposta armazenada já está pronta para ser utilizada.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
27
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
É basicamente um contrato para comunicação entre cliente e servidor. São regras para
fazer um componente o mais genérico possível, tornando-o muito mais fácil de ser
refatorado e melhorado. Obedece a quatro princípios: identificação de recursos;
representação de recursos; respostas auto-explicativas; e hypermídia.
Esse princípio é opcional, na medida em que não faz parte da arquitetura em si. Ele trata da
possibilidade de clientes poderem estender suas funcionalidades através do download e
execução do código sob demanda. Exemplos incluem scripts Javascript, Applets Java,
Silverlight, e assim por diante.
Em outras palavras, permite que o cliente possa executar algum código sob demanda, ou
seja, estender parte da lógica do servidor para o cliente, seja através de applets ou scripts.
Assim, diferentes clientes podem se comportar de maneiras específicas mesmo que
utilizando exatamente os mesmos serviços providos pelo servidor.
Aplicações que sigam essas restrições são consideradas Aplicações RESTful. Como vocês
devem ter notado, essas restrições não ditam a tecnologia a ser utilizada para o desenvolvimento
das aplicações. Em vez disso, a adesão a estas orientações e melhores práticas oferece a
oportunidade de uma aplicação escalável, visível, portátil, confiável e capaz de performar
melhor.
Em teoria, é possível que uma aplicação RESTful seja construída utilizando qualquer
infraestrutura de rede ou protocolo de transporte. Na prática, aplicações RESTful levam
vantagem ao utilizar características e recursos da web e o protocolo HTTP (e seus
métodos/verbos: GET, POST, PUT, DELETE5). Grosso modo, esses métodos servem
respectivamente para recuperar, inserir, atualizar e deletar um recurso.
Por exemplo, em um aplicativo de comércio eletrônico, o cliente pode fazer um pedido para
qualquer número de produtos. Neste cenário, os recursos de produtos estão relacionados com
o recurso de pedido correspondente. É também possível que recursos sejam agrupados em
conjuntos. Usando o mesmo exemplo de comércio eletrônico, uma ordem é uma coleção de
recursos individuais de pedidos.
5
O Protocolo HTTP possui diversos métodos (GET, POST, PUT, DELETE, OPTIONS, TRACE, HEAD, CONNECT), no entanto os quatro tem maior
relevância em nosso contexto.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
28
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
E o que é uma URI? Trata-se do Uniform Resource Identifier, que nada mais é que uma string
de caracteres utilizada para identificar unicamente um recurso. Vocês já devem conhecer a
URL (Uniform Resource Locator) – trata-se de uma URI que, além de identificar um recurso da
web, também é capaz de localizá-lo (basta lembrar de endereços de sites). No REST, todo
recurso contém um identificador.
Já que entramos nesse assunto, vamos falar um pouco sobre WS-* (JAX-WS) e REST (JAX-RS).
Em sua implementação tradicional, desenvolvem-se Web Services utilizando o Protocolo
SOAP e, em geral, com a Linguagem XML – no Java, essa especificação foi denominada JAX-
WS (Java API for XML Web Services), presente a partir do Java EE 5. Tudo certo até aqui?
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
29
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Na imagem acima, podemos ver REST e SOAP! No primeiro caso, se você quiser enviar uma
mensagem a alguém que está em outra cidade, você pode simplesmente subir no cavalo
(HTTP) e cavalgar! Simples assim... agora vejam o SOAP! Para você enviar a mesma mensagem,
você precisa de vários cavalos e uma carruagem imensa e pesada que envolve a mensagem.
Observem outra diferença importante! No SOAP, existe uma especificação que deve ser seguida
para todas as requisições/respostas – trata-se do WSDL. No REST, não existia nenhuma
especificação. Hoje em dia, podemos utilizar o WSDL2 ou WADL para descrever um serviço.
Bacana? Agora percebam a complexidade que é enviar uma mensagem no SOAP x REST! Vejam
o overhead que traz o envelope...
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
30
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
JavaScript pode chamar SOAP, mas é difícil de JavaScript pode facilmente chamar REST.
implementar.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
31
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
QUESTÕES COMENTADAS
services
Comentários:
Gabarito: Correto
Comentários:
No contexto de Web Services, o que é um “documento XML utilizado para troca de mensagens”? É
um Web Service SOAP! Nesse caso, o elemento principal do maior nível hierárquico é o Envelope
– que identifica a Mensagem SOAP. No entanto, um namespace é apenas um nome que
identifica um conjunto de outros nomes! Ele pode representar o nome do elemento de maior
nível hierárquico assim como quaisquer outros.
Gabarito: Errado
3. (CESPE – 2017 – SE/DF) Serviços expressos por meio de contratos web services têm o
potencial de evitar completamente a transformação, objetivo-chave dos contratos de
serviços padronizados.
Comentários:
Galera, essa questão afirma que quando eu ofereço serviços por meio de Web Services e seus
contratos (i.e., suas interfaces), eu tenho um grande potencial de evitar a transformação. Isso é
verdade! Nós sabemos que mudar a implementação do serviço é irrelevante desde que se
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
32
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Logo, o contrato não é imutável, ele realmente muda raramente, mas ele não é imune a
mudanças e não evita completamente transformações. No entanto, a questão afirma que o uso
de contratos tem o “potencial” de evitar completamente a transformação. Ter o potencial
significa ter a capacidade de realização ou execução de algo. E isso é verdadeiro nesse contexto.
Vejam o que diz a especificação:
“Regardless of the development approach you utilize for service development there is no question
that service contracts must be designed in an extensible manner to minimize disruptive versioning
changes. Service contracts should be designed with the assumption that once published, they
cannot be modified—this approach forces developers to build flexibility into their schema designs”.
Gabarito: Errado
Comentários:
Conforme eu disse na questão anterior, contratos de serviços (interfaces) espalhadas pela rede e
desacopladas, permitindo que o contrato seja padronizado, sendo sua implementação
irrelevante.
Gabarito: Correto
a) WS – Transaction é um padrão de suporte que garante que uma mensagem seja entregue
uma vez e apenas uma vez.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
33
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
d) WSDL (web service definition language) na SOA para Web é uma linguagem utilizada
como padrão para troca de mensagens e para definição de componentes de web services.
e) WS – realiable messaging é um padrão SOA que define como as informações devem ser
representadas em uma mensagem SOAP.
Comentários:
Gabarito: Letra B
6. (CESPE – 2017 – TRE/BA) No que se refere a web services, assinale a opção correta.
a) As solicitações e respostas XML trafegam no protocolo HTTP, não sendo possível utilizá-
las nos protocolos FTP e SMTP.
b) Um dos componentes de um Web Service SOAP (Simple Object Access Protocol) é a UDDI
(Universal Description, Discovery and Integration), a qual é um arquivo do tipo XML que
descreve detalhadamente um Web Service, especificando como deve ser o formato de
entrada e saída de cada operação.
c) As duas formas de envio de mensagem para que um cliente possa efetuar solicitações a um
Web Service são One-Way Messaging e Request-Response Messaging.
Comentários:
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
34
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
(a) Errado. Via de regra, utiliza-se HTTP, mas não obrigatório; (b) Errado. Observem que a
questão não está afirmando que UDDI é um componente do SOAP. Ela afirma que o UDDI é um
componente do Web Service SOAP. Dito isso, quem descreve detalhadamente um serviço é o
WSDL; (c) Correto. Existem quatro tipos de operação: One-Way, Request/Response,
Solicit/Response e Notification. Para que o cliente possa efetuar solicitações, é adequado utilizar
as duas primeiras; (d) Errado, não é para desenvolvimento – é para descrição de Web Services;
(e) Errado, eles são independentes de tecnologia, logo não dependem de linguagem de
programação ou sistema operacional.
Gabarito: Letra C
I. HTML POST é utilizado para enviar dados para serem processados em um servidor Web.
II. HTML GET solicita ao servidor apenas o cabeçalho de uma URL para que o cliente decida
se deve requisitar o conteúdo completo ou não.
III. HTML PUT é utilizado para criar recursos dentro de um servidor Web.
a) I e II, apenas.
b) I e III, apenas.
c) II e III, apenas.
d) I, II e III.
Comentários:
Esse método solicita ao servidor que envie uma página (ou um objeto, no caso mais genérico; na
prática, apenas um arquivo). A grande maioria das solicitações a servidores da web tem a forma
de métodos GET.
Esse método é o inverso do GET, i.e., em vez de ler, ele grava a página. Esse método possibilita a
criação de um conjunto de páginas da web em um servidor remoto – o corpo da solicitação
contém a página.
Esse método é semelhante ao PUT – porque também transporta um URL –, no entanto, em vez
de substituir os dados existentes, os novos dados são "anexados" a ele, em um sentido mais
genérico. Na prática, nem PUT nem POST são muito utilizados hoje.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
35
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Todos os itens estão corretos, exceto o segundo! Na verdade, o método que solicita o cabeçalho
de um recurso é o HEAD. Vocês já notaram o vacilo da banca? Pois é, esses métodos são do HTTP
e, não, HTML.
Gabarito: Letra B
8. (FAU - 2016 – JUCEPAR/PR) Que nome é dado aos pequenos arquivos que são gravados em
seu computador quando você acessa sites na Internet e que são reenviados a estes mesmos
sites quando novamente visitados?
a) Planilhas.
b) Cookies.
c) Trojan.
d) Virus.
e) Token.
Comentários:
Muito cuidado para não confundir cookies com algo nativamente inseguro. Qualquer recurso na
web pode conter vulnerabilidades e ser explorado por um hacker. Os cookies são muito
importantes e uma definição bem aceitável é apresentada no enunciado da questão, como vimos
na aula teórica.
Gabarito: Letra B
9. (IESES - 2015 – TRE/MA) Das definições abaixo sobre cookies, assinale a afirmativa correta.
b) Arquivo gerado pelo servidor WEB que fica armazenado na máquina do usuário e que
permite ao servidor buscar informações realizadas pelo usuário no site.
d) O cookie Web é arquivo que fica armazenado na máquina do usuário e que aumenta a
performance de navegação na WEB.
Comentários:
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
36
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
(a) Errado. É complicado dizer que ter um cookie habilitado reduz a segurança do usuário. Com
certeza reduz a privacidade, pois, no mínimo, eles são usados para enviar informações da
navegação do usuário aos servidores web. O contrário então, não tem como afirmar! Ou seja, os
cookies não aumentam a segurança do usuário; (b) Correto. Uma boa definição de cookies; (c)
Errado. Na verdade vimos que o servidor web deve enviar, normalmente via HTTP, no cabeçalho
um elemento Set-Cookie; (d) Errado. O cookie não melhora a performance da navegação.
Gabarito: Letra B
10. (FAU - 2016 – JUCEPAR/PR) Assinale a alternativa correta que contenha a definição de
Cookie:
b) Vírus que captura informações do usuário digitadas no navegador e as envia por e-mail
para um computador receptor.
Comentários:
(a) Correto. Boa definição para cookies. Ele armazena muito mais que isso, mas também as
preferências do usuário; (b) Errado. Cookies não são vírus; (c) Errado. No máximo um atributo
Secure para dizer ao user agente para que, ele sim, “se vire” com a segurança. O cookie não
garante segurança; (d) Errado. Cookie não é um protocolo, e não garante segurança; (e) Errado.
Cookie não é um certificado digital.
Gabarito: Letra A
11. (FGV - 2016 - COMPESA) Quando um navegador solicita uma página da web, o servidor pode
fornecer informações adicionais junto com a página solicitada. Essas informações podem
incluir um cookie.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
37
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
I. Uma linha no cabeçalho HTTP iniciada por Cookie: é a forma como os servidores enviam
cookies aos clientes. Espera-se que o cliente grave o cookie e o devolva em solicitações
subsequentes ao servidor.
II. Para remover um cookie do disco rígido do cliente, basta o servidor enviá-lo novamente
com uma data de expiração vencida.
III. Um cookie que não contém a informação de quando irá expirar permanece ativo por
tempo indeterminado.
a) I, apenas.
b) II, apenas.
c) III, apenas.
d) I e II, apenas.
e) I, II e III.
Comentários:
I – Errado. Na verdade, temos que incluir no cabeçalho Set-Cookie, e não somente Cookie;
II – Correto. Vimos na aula teórica que uma data vencida no atributo Expires faz com que o cookie
seja removido pelo User Agent;
III – Errado. Como vimos na aula teórica, o cookie ficará armazenado até o fim da sessão, pelo
tempo que o próprio User Agent definir. Ou seja, o tempo não é indefinido, mas sim definido pela
sessão do usuário.
Gabarito: Letra B
12. (IBFC / EBSERH – 2017) Assinale a alternativa que apresenta o serviço de diretório onde
empresas podem registrar (publicar) e buscar (descobrir) por Serviços Web (Web Services):
a) UDDI
b) NIS
c) WSDL
d) X.500
e) LDAP
Comentários:
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
38
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Gabarito: Letra A
13. (IBFC / EBSERH – 2017) Web service é uma solução utilizada na integração de sistemas. Os
Web services são componentes que permitem às aplicações enviar e receber dados, como
padrão, em formato:
a) NAT
b) ARP
c) XML
d) TLS
e) XDR.
Comentários:
Galera, o formato padrão de Web Services (SOAP) é o XML! As outras opções não fazem o menor
sentido...
Gabarito: Letra C
14. (IBFC / EBSERH – 2017) Conforme o W3C (World Wide Web Consortium) pode-se definir um
Web Service como sendo:
Comentários:
(a) Errado, acredito que isso seria um modelo de processo de software; (b) Errado, acredito que
isso seria o processo de software de métodos formais; (c) Errado, acredito que isso seria mais
relacionado ao CMMI; (d) Correto, ele é extremamente útil para suportar interoperabilidade na
troca de informações entre máquinas da rede; (e) Errado, acredito que isso seria mais relacionado
ao modelo entidade relacionamento.
Gabarito: Letra D
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
39
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
15. (IBFC / EMDEC – 2016) Quanto as tecnologias aplicadas em um Web Service temos:
Comentários:
Gabarito: Letra D
16. (CESPE - 2016 – TCE/SC) A JAX-RS 2.0 fornece APIs portáteis para o desenvolvimento de
aplicações Web em conformidade com os princípios do estilo arquitetônico REST.
Comentários:
O JAX-RS – como o próprio nome sugere – fornece APIs portáteis para o desenvolvimento de
aplicações web em conformidade com o REST.
Gabarito: Correto
17. (CESPE - 2015 – MEC) Entre as restrições da REST está a interface uniforme, a qual requer
que um serviço ofereça várias operações e aguarde a solicitação dessas operações pelo
servidor.
Comentários:
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
40
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
É basicamente um contrato para comunicação entre cliente e servidor. São regras para
fazer um componente o mais genérico possível, tornando-o muito mais fácil de ser
refatorado e melhorado. Obedece a quatro princípios: identificação de recursos;
representação de recursos; respostas auto-explicativas; e hypermídia.
A questão não trata da restrição de Interface Uniforme. Acredito que a restrição que mais se
aproxima dessa descrição seja o Sistema em Camadas.
Gabarito: Errado
18. (CESPE - 2015 – MEC) A fim de implementar serviços em REST, recomenda-se utilizar os
WSDL já existentes com mínima alteração do cabeçalho, informando somente que o
protocolo a ser utilizado é o REST.
Comentários:
Em teoria, é possível que uma aplicação RESTful seja construída utilizando qualquer infraestrutura
de rede ou protocolo de transporte. Na prática, aplicações RESTful levam vantagem ao utilizar
características e recursos da web e o protocolo HTTP (e seus métodos/verbos: GET, POST, PUT,
DELETE). Grosso modo, esses métodos servem respectivamente para recuperar, inserir, atualizar e
deletar um recurso.
Quem utiliza WSDL é o estilo arquitetural WS-*. O estilo arquitetural REST utiliza o protocolo
HTTP.
Gabarito: Errado
19. (CESPE - 2016 – MEC) A respeito dos conceitos de web services e REST, assinale a opção
correta.
b) Pode-se utilizar qualquer meio de transporte existente para o envio de uma requisição,
incluindo HTTP, SMTP e TCP.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
41
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
e) As chamadas às URIs (uniform resource indicator) são feitas por meio de métodos HTTP,
os quais indicam para o serviço a ação a ser realizada com o recurso.
Comentários:
Em teoria, é possível que uma aplicação RESTful seja construída utilizando qualquer infraestrutura
de rede ou protocolo de transporte. Na prática, aplicações RESTful levam vantagem ao utilizar
características e recursos da web e o protocolo HTTP (e seus métodos/verbos: GET, POST, PUT,
DELETE). Grosso modo, esses métodos servem respectivamente para recuperar, inserir, atualizar e
deletar um recurso.
(a) Conforme vimos em aula, PUT é o método utilizado para atualizar recursos;
Em teoria, é possível que uma aplicação RESTful seja construída utilizando qualquer infraestrutura
de rede ou protocolo de transporte. Na prática, aplicações RESTful levam vantagem ao utilizar
características e recursos da web e o protocolo HTTP (e seus métodos/verbos: GET, POST, PUT,
DELETE). Grosso modo, esses métodos servem respectivamente para recuperar, inserir, atualizar e
deletar um recurso.
(b) Conforme vimos em aula, pode-se utilizar diversos meios de transporte, no entanto TCP não
é um meio de transporte (é um conjunto de protocolos).
(d) Na verdade, quando se requisita uma aplicação ao servidor, os recursos são transferidos pela
rede. Da maneira que está escrita, essa questão nem faz sentido.
(e) Conforme vimos em aula, a questão está impecável. Percebam que ela não limita o uso ao
HTTP – apenas o menciona.
Gabarito: Letra E
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
42
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
20. (CESPE - 2015 – TRE/MT) Acerca de REST (representational state transfer), assinale a opção
correta.
Comentários:
(a) Conforme vimos em aula, ele não utiliza esses formatos (além disso, não é um protocolo).
E o que é uma URI? Trata-se do Uniform Resource Identifier, que nada mais é que uma string de
caracteres utilizada para identificar unicamente um recurso. Vocês já devem conhecer a URL
(Uniform Resource Locator) – trata-se de uma URI que, além de identificar um recurso da web,
também é capaz de localizá-lo (basta lembrar de endereços de sites). No REST, todo recurso contém
um identificador.
(b) Conforme vimos em aula, ele utiliza – sim – recursos identificáveis (para isso, temos a URI).
Observem outra diferença importante! No SOAP, existe uma especificação que deve ser seguida
para todas as requisições/respostas – trata-se do WSDL. No REST, não existia nenhuma
especificação. Hoje em dia, podemos utilizar o WSDL2 ou WADL para descrever um serviço.
Bacana? Agora percebam a complexidade que é enviar uma mensagem no SOAP x REST! Vejam o
overhead que traz o envelope...
(c) Conforme vimos em aula, em relação ao SOAP, o REST tem baixíssimo overhead.
E o que é uma URI? Trata-se do Uniform Resource Identifier, que nada mais é que uma string de
caracteres utilizada para identificar unicamente um recurso. Vocês já devem conhecer a URL
(Uniform Resource Locator) – trata-se de uma URI que, além de identificar um recurso da web,
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
43
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
também é capaz de localizá-lo (basta lembrar de endereços de sites). No REST, todo recurso contém
um identificador.
Responsabilidades devem ser separadas entre clientes e servidores. Isso permite que os
componentes do cliente e do servidor evoluam de forma independente e, por sua vez,
permite que o sistema seja escalável. Em outras palavras, busca-se separar a arquitetura
e responsabilidades em dois ambientes.
Dessa forma, o cliente não se preocupa com tarefas do tipo: comunicação com banco de
dados, gerenciamento de cache, log, etc; e o contrário também é válido, o servidor não
se preocupa com tarefas como: interface, experiência do usuário, etc. Permitindo,
assim, a evolução independente das duas arquiteturas.
(e) Conforme vimos em aula, ele – de fato – utiliza uma interação cliente/servidor, no entanto ele
não é um estilo de desenvolvimento e não é uma interação complexa, pelo contrário: é bem
simples.
Gabarito: Letra C
21. (CESPE - 2016– TRE/PI) Acerca de REST (Representational State Transfer), assinale a opção
correta.
Comentários:
Em teoria, é possível que uma aplicação RESTful seja construída utilizando qualquer infraestrutura
de rede ou protocolo de transporte. Na prática, aplicações RESTful levam vantagem ao utilizar
características e recursos da web e o protocolo HTTP (e seus métodos/verbos: GET, POST, PUT,
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
44
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
DELETE). Grosso modo, esses métodos servem respectivamente para recuperar, inserir, atualizar e
deletar um recurso.
(a) Errado, claro que não! Você pode não ter permissão para acessar um recurso, por exemplo.
Nem todos os recursos respondem a todos os métodos; (b) Errado, ele permite obter, mas não
alterar o estado atual de um recurso; (c) Errado, esse método não existe; (d) Na minha opinião, é
impossível responder esse item. Modelo rígido em relação ao quê? O REST é um modelo flexível;
a comunicação pode ser considerada rígida ou flexível dependendo da comparação; (e) Errado,
esse método não existe. Portanto, para mim, essa questão deveria ter sido anulada, mas o
gabarito é Letra D.
Gabarito: Letra D
22. (CESPE – 2016 – FUNPRESP) Conexões REST devem conter todas as informações
necessárias para que a conexão seja completada.
Comentários:
A comunicação entre cliente e servidor deve ser stateless. O servidor não precisa lembrar o
estado do cliente. Em vez disso, os clientes devem incluir todas as informações necessárias
na requisição para que o servidor possa entendê-la e processá-la.
Em outras palavras, um mesmo cliente pode mandar várias requisições para o servidor,
porém cada uma delas deve ser independente, ou seja, toda requisição deve conter todas
as informações necessárias para que o servidor consiga entendê-la e processá-la
adequadamente (qualquer informação de estado deve ficar no cliente).
O “ST” em REST significa “State Transfer”, i.e., as operações devem ser autocontidas e cada
requisição deve carregar consigo (Transferir) toda informação (Estado) que o servidor precisará
para processá-la. Então, de fato, conexões devem conter todas as informações necessárias para
que a conexão seja completada com sucesso.
Gabarito: Correto
23. (CESPE – 2015 – TJDFT) Em um Web Service RESTful, cada método é identificado por uma
URL única. Assim, quando o servidor recebe uma solicitação, ele identifica de forma
inequívoca a operação que será executada.
Comentários:
Essa questão é bizarra! Ela afirma que cada método é identificado por uma URL única. Na
verdade, todos os métodos têm a mesma URL. Cada Web Service tem uma URL única e contém
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
45
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
vários métodos. Ao invocar um serviço web, é necessário especificar qual o método pretendido
e os parâmetros necessários para esse método. Cada método de serviço web retorna uma
resposta que contém os resultados da execução do cliente. Honestamente, não entendi esse
gabarito!
Gabarito: Correto
24. (CESPE – 2015 – FUB) Em REST, os conectores precisam reter o estado das aplicações entre
as requisições, visto que eles dependem de informações de requisições que as antecederam
para entender determinada requisição.
Comentários:
A comunicação entre cliente e servidor deve ser stateless. O servidor não precisa lembrar o
estado do cliente. Em vez disso, os clientes devem incluir todas as informações necessárias
na requisição para que o servidor possa entendê-la e processá-la.
Em outras palavras, um mesmo cliente pode mandar várias requisições para o servidor,
porém cada uma delas deve ser independente, ou seja, toda requisição deve conter todas
as informações necessárias para que o servidor consiga entendê-la e processá-la
adequadamente (qualquer informação de estado deve ficar no cliente).
Não é necessário manter o estado das aplicações entre as requisições – essa é uma questão
recorrente.
Gabarito: Errado
c) uma linguagem web voltada a definição de predicados que se apliquem a classes de objetos
e de interações em um modelo UML.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
46
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Comentários:
Pessoal, essa questão tem quatro itens que não fazem o menor sentido, logo vamos comentar
direto o primeiro item. Notem só o nosso dilema! Eu falei para vocês diversas vezes que o REST
é um Estilo Arquitetural. O gabarito da questão afirma que REST é um Estilo de
Desenvolvimento. Ora, na minha opinião, questão errada e ponto final! Simples assim...
Porééééééém esse item foi retirado diretamente da última versão do Sommerville (9ª Ed.) e ele
afirma exatamente assim:
“REST é um estilo de desenvolvimento baseado em interação simples de cliente /servidor e que usa
o protocolo HTTP. REST é baseado na ideia de recurso identificável, o qual possui uma URI. Todas
as interações com recursos são baseadas em HTTP POST, GET, PUT e DELETE. Atualmente é muito
usado para implementar web services de baixo overhead”.
O que isso significa? Isso significa que, a partir de agora, vamos ter que considerar o REST – pelo
menos no contexto de provas de concurso – também como um Estilo de Desenvolvimento. Eu
discordo veementemente, não vejo o menor sentido nessa afirmação. Porém, contudo, todavia,
entretanto, se o Sommerville diz, vira referência! Bacana?
Gabarito: Letra A
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
47
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
LISTA DE QUESTÕES
services
3. (CESPE – 2017 – SE/DF) Serviços expressos por meio de contratos web services têm o
potencial de evitar completamente a transformação, objetivo-chave dos contratos de
serviços padronizados.
a) WS – Transaction é um padrão de suporte que garante que uma mensagem seja entregue
uma vez e apenas uma vez.
d) WSDL (web service definition language) na SOA para Web é uma linguagem utilizada
como padrão para troca de mensagens e para definição de componentes de web services.
e) WS – realiable messaging é um padrão SOA que define como as informações devem ser
representadas em uma mensagem SOAP.
6. (CESPE – 2017 – TRE/BA) No que se refere a web services, assinale a opção correta.
a) As solicitações e respostas XML trafegam no protocolo HTTP, não sendo possível utilizá-
las nos protocolos FTP e SMTP.
b) Um dos componentes de um Web Service SOAP (Simple Object Access Protocol) é a UDDI
(Universal Description, Discovery and Integration), a qual é um arquivo do tipo XML que
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
48
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
c) As duas formas de envio de mensagem para que um cliente possa efetuar solicitações a um
Web Service são One-Way Messaging e Request-Response Messaging.
I. HTML POST é utilizado para enviar dados para serem processados em um servidor Web.
II. HTML GET solicita ao servidor apenas o cabeçalho de uma URL para que o cliente decida
se deve requisitar o conteúdo completo ou não.
III. HTML PUT é utilizado para criar recursos dentro de um servidor Web.
a) I e II, apenas.
b) I e III, apenas.
c) II e III, apenas.
d) I, II e III.
8. (FAU - 2016 – JUCEPAR/PR) Que nome é dado aos pequenos arquivos que são gravados em
seu computador quando você acessa sites na Internet e que são reenviados a estes mesmos
sites quando novamente visitados?
a) Planilhas.
b) Cookies.
c) Trojan.
d) Virus.
e) Token.
9. (IESES - 2015 – TRE/MA) Das definições abaixo sobre cookies, assinale a afirmativa correta.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
49
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
b) Arquivo gerado pelo servidor WEB que fica armazenado na máquina do usuário e que
permite ao servidor buscar informações realizadas pelo usuário no site.
d) O cookie Web é arquivo que fica armazenado na máquina do usuário e que aumenta a
performance de navegação na WEB.
10. (FAU - 2016 – JUCEPAR/PR) Assinale a alternativa correta que contenha a definição de
Cookie:
b) Vírus que captura informações do usuário digitadas no navegador e as envia por e-mail
para um computador receptor.
11. (FGV - 2016 - COMPESA) Quando um navegador solicita uma página da web, o servidor pode
fornecer informações adicionais junto com a página solicitada. Essas informações podem
incluir um cookie.
I. Uma linha no cabeçalho HTTP iniciada por Cookie: é a forma como os servidores enviam
cookies aos clientes. Espera-se que o cliente grave o cookie e o devolva em solicitações
subsequentes ao servidor.
II. Para remover um cookie do disco rígido do cliente, basta o servidor enviá-lo novamente
com uma data de expiração vencida.
III. Um cookie que não contém a informação de quando irá expirar permanece ativo por
tempo indeterminado.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
50
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
a) I, apenas.
b) II, apenas.
c) III, apenas.
d) I e II, apenas.
e) I, II e III.
12. (IBFC / EBSERH – 2017) Assinale a alternativa que apresenta o serviço de diretório onde
empresas podem registrar (publicar) e buscar (descobrir) por Serviços Web (Web Services):
a) UDDI
b) NIS
c) WSDL
d) X.500
e) LDAP
13. (IBFC / EBSERH – 2017) Web service é uma solução utilizada na integração de sistemas. Os
Web services são componentes que permitem às aplicações enviar e receber dados, como
padrão, em formato:
a) NAT
b) ARP
c) XML
d) TLS
e) XDR.
14. (IBFC / EBSERH – 2017) Conforme o W3C (World Wide Web Consortium) pode-se definir um
Web Service como sendo:
15. (IBFC / EMDEC – 2016) Quanto as tecnologias aplicadas em um Web Service temos:
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
51
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
16. (CESPE - 2016 – TCE/SC) A JAX-RS 2.0 fornece APIs portáteis para o desenvolvimento de
aplicações Web em conformidade com os princípios do estilo arquitetônico REST.
17. (CESPE - 2015 – MEC) Entre as restrições da REST está a interface uniforme, a qual requer
que um serviço ofereça várias operações e aguarde a solicitação dessas operações pelo
servidor.
18. (CESPE - 2015 – MEC) A fim de implementar serviços em REST, recomenda-se utilizar os
WSDL já existentes com mínima alteração do cabeçalho, informando somente que o
protocolo a ser utilizado é o REST.
19. (CESPE - 2016 – MEC) A respeito dos conceitos de web services e REST, assinale a opção
correta.
b) Pode-se utilizar qualquer meio de transporte existente para o envio de uma requisição,
incluindo HTTP, SMTP e TCP.
e) As chamadas às URIs (uniform resource indicator) são feitas por meio de métodos HTTP,
os quais indicam para o serviço a ação a ser realizada com o recurso.
20. (CESPE - 2015 – TRE/MT) Acerca de REST (representational state transfer), assinale a opção
correta.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
52
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
21. (CESPE - 2016– TRE/PI) Acerca de REST (Representational State Transfer), assinale a opção
correta.
22. (CESPE – 2016 – FUNPRESP) Conexões REST devem conter todas as informações
necessárias para que a conexão seja completada.
23. (CESPE – 2015 – TJDFT) Em um Web Service RESTful, cada método é identificado por uma
URL única. Assim, quando o servidor recebe uma solicitação, ele identifica de forma
inequívoca a operação que será executada.
24. (CESPE – 2015 – FUB) Em REST, os conectores precisam reter o estado das aplicações entre
as requisições, visto que eles dependem de informações de requisições que as antecederam
para entender determinada requisição.
c) uma linguagem web voltada a definição de predicados que se apliquem a classes de objetos
e de interações em um modelo UML.
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
53
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
54
55
74650440220 - igson medes da silva
Diego Carvalho, Fernando Pedrosa Lopes
Aula 10
1183466
GABARITO
1. CORRETO
2. ERRADO
3. ERRADO
4. CORRETO
5. LETRA B
6. LETRA C
7. LETRA B
8. LETRA B
9. LETRA B
10. LETRA A
11. LETRA B
12. LETRA A
13. LETRA C
14. LETRA D
15. LETRA D
16. CORRETO
17. ERRADO
18. ERRADO
19. LETRA E
20. LETRA C
21. LETRA D
22. CORRETO
23. CORRETO
24. ERRADO
25. LETRA A
Engenharia de Software p/ TCE-AM (Auditor Controle Externo - TI) 2021 FGV - Pré-Edital
www.estrategiaconcursos.com.br
55
55
74650440220 - igson medes da silva