24.aula 17 - Web Services - Introdução e Conceitos

1
Disciplina: Desenvolvimento Web I
Web Services
Introdução e conceitos
Prof. Eder Pansani

E-mail: epansani@gmail.com
29 de novembro de 2017 http://ederpansani.com.br
2
Conteúdo da aula
● Web services
– Introdução e conceitos
– O protocolo HTTP
– SOAP
– REST & RESTful
Prof. Eder Pansani

3
Introdução e definições
De acordo com o W3C (World Wide Web
Consortium) um Web Service define-se
como: um sistema de software projetado
para suportar a interoperabilidade entre
máquinas sobre rede.
Prof. Eder Pansani

4
Webservice é uma solução utilizada na integração
de sistemas e na comunicação entre aplicações
diferentes. Com esta tecnologia é possível que
novas aplicações possam interagir com aquelas
que já existem e que sistemas desenvolvidos em
plataformas diferentes sejam compatíveis
Prof. Eder Pansani

5
De forma sucinta pode-se dizer que os web
services permitem que diferentes
aplicações possam interagir.
Prof. Eder Pansani

6
Exemplo
Por exemplo, imagine uma situação onde
uma solução de automação que utiliza
arduíno (ou raspberry pi) para monitorar
um ambiente, temperatura, umidade,
pressão, etc.
Prof. Eder Pansani

7
Exemplo
Esta solução precisa coletar todos estes
dados e fazer sua persistência em um
banco de dados e uma aplicação que faz
seu processamento.
Prof. Eder Pansani

8
Exemplo
Todos os dados de centenas de
localidades distintas devem ser submetidos
a um sistema de Business Inteligence que
faz análises e devolve novas informações,
que também devem ser persistidas.
Prof. Eder Pansani

9
Exemplo
Os clientes desta solução querem
consumir apenas os resultados finais em
uma interface web e também em um
aplicativo nos smartphones. Logo os dados
devem ser acessíveis a ambas as
plataformas.
Prof. Eder Pansani
10
Exemplo
Prof. Eder Pansani

11
Nesta situação pode-se imaginar que serão
empregadas distintas tecnologias, no
entanto todas elas precisarão se
comunicar. Essa é uma das aplicações de
um web service.
Prof. Eder Pansani

12
Vantagens
Algumas das vantagens de se utilizar web
services são:
● Simplicidade na interoperabilidade de
sistemas
Prof. Eder Pansani

13
Vantagens
● Independência de tecnologia de
desenvolvimento e plataformas, visto que
é possível criar web services usando
diferentes linguagens de programação.
Prof. Eder Pansani

14
Vantagens
● Segurança, uma vez que não há um
acesso direto à informação (que está na
base de dados).
Prof. Eder Pansani

15
Vantagens
● Redução de custos, um Web Service
pode servir vários tipos de
aplicações/serviços (reutilização de
código)
Prof. Eder Pansani

16
O protocolo HTTP
Quando se fala em web services é
necessário ter um pouco de conhecimento
sobre o protocolo HTTP e seu
funcionamento básico.
Prof. Eder Pansani

17
O protocolo HTTP
De forma bastante simplificada “o protocolo
HTTP (Hypertext Transfer Protocol) é o
método utilizado para enviar e receber
informações na web”
Prof. Eder Pansani

18
O protocolo HTTP
O protocolo HTTP é baseado em
requisições e respostas entre clientes e
servidores.
Prof. Eder Pansani

19
O protocolo HTTP
O cliente — navegador ou dispositivo que fará a
requisição; também é conhecido como user
agent — solicita um determinado recurso
(resource), enviando um pacote de informações
contendo alguns cabeçalhos (headers) a um URI
ou, mais especificamente, URL.
Prof. Eder Pansani

20
O protocolo HTTP
O servidor recebe estas informações e
envia uma resposta, que pode ser um
recurso ou um simplesmente um outro
cabeçalho.
Prof. Eder Pansani

21
O protocolo HTTP
Exemplo de um cabeçalho:
Prof. Eder Pansani

22
O protocolo HTTP
É posível observar neste cabeçalho qual o
servidor que está recebendo a solicitação
(host), as informações que estamos
enviando, o método, etc.
Prof. Eder Pansani

23
O protocolo HTTP
Veja a resposta:
Prof. Eder Pansani

24
O protocolo HTTP
Nos cabeçalhos de resposta, você pode
obter algumas informações importantes
como o código de resposta (Status). Este
código identifica se uma requisição foi
concluída com sucesso (200) ou se ela não
existe (404), por exemplo.
Prof. Eder Pansani
25
O protocolo HTTP
É possível observar também informações
do servidor, como sua versão, dados sobre
cache, formato e codificação de caracteres
da resposta entre outras.
Prof. Eder Pansani

26
O protocolo HTTP
Métodos HTTP
Quando você vai fazer uma requisição, é preciso que

você especifique qual o método será utilizado. Os
métodos HTTP, também conhecidos como verbos,
identificam qual a ação que deve ser executada em
um determinado recurso. Existem 8 métodos HTTP,
mas apenas 5 são mais utilizados.
Prof. Eder Pansani
27
O protocolo HTTP
GET
Solicita a representação de um determinado

recurso. É definido como um método
seguro e não deve ser usado para disparar
uma ação (remover um usuário, por
exemplo).
Prof. Eder Pansani
28
O protocolo HTTP
POST
As informações enviadas no corpo (body) da

requisição são utilizadas para criar um novo
recurso. Também é responsável por fazer
processamentos que não são diretamente
relacionados a um recurso.
Prof. Eder Pansani
29
O protocolo HTTP
DELETE
Remove um recurso. Deve retornar o

status 204 caso não exista nenhum recurso
para a URI especificada.
Prof. Eder Pansani

30
O protocolo HTTP
PUT
Atualiza um recurso na URI especificada.

Caso o recurso não exista, ele pode criar um.
A principal diferenteça entre POST e PUT é
que o primeiro pode lidar não somente com
recursos, mas pode fazer processamento de
informações, por exemplo.
Prof. Eder Pansani
31
O protocolo HTTP
HEAD
Retorna informações sobre um recurso. Na

prática, funciona semelhante ao método
GET, mas sem retornar o recurso no corpo
da requisição. Também é considerado um
método seguro.
Prof. Eder Pansani
32
O protocolo HTTP
Os outros métodos disponíveis são
OPTIONS, TRACE e CONNECT. Em
teoria, os servidores devem implementar
os métodos GET e HEAD e, sempre que
possível, o método OPTIONS.
Prof. Eder Pansani

33
O protocolo HTTP
Status
Toda requisição recebe um código de

resposta conhecido como status. Com o
status é possível saber se uma operação foi
realizada com sucesso (200), se ele foi
movida e agora existe em outro lugar (301)
ou se não existe mais (404).
Prof. Eder Pansani
34
O protocolo HTTP
200 OK - A requisição foi bem sucedida.
301 Moved Permanently - O recurso foi
movido permanentemente para outra URI.
302 Found - O recurso foi movido
temporariamente para outra URI.
304 Not Modified - O recurso não foi
alterado.
Prof. Eder Pansani
35
O protocolo HTTP
401 Unauthorized - A URI especificada exige
autenticação do cliente. O cliente pode tentar
fazer novas requisições.
403 Forbidden - O servidor entende a
requisição, mas se recusa em atendê-la. O
cliente não deve tentar fazer uma nova
requisição.
404 Not Found - O servidor não encontrou
nenhuma URI correspondente.
Prof. Eder Pansani
36
O protocolo HTTP
405 Method Not Allowed - O método
especificado na requisição não é válido na
URI. A resposta deve incluir um cabeçalho
Allow com uma lista dos métodos aceitos.
500 Internal Server Error - O servidor não
foi capaz de concluir a requisição devido a
um erro inesperado.
Prof. Eder Pansani
37
O protocolo HTTP
502 Bad Gateway - O servidor, enquanto
agindo como proxy ou gateway, recebeu
uma resposta inválida do servidor
upstream a que fez uma requisição.
503 Service Unavailable - O servidor não
é capaz de processar a requisição pois
está temporariamente indisponível.
Prof. Eder Pansani
38
O protocolo HTTP
O propósito desta breve discussão sobre o
protocolo HTTP é ter um mínimo de
conhecimento sobre seu funcionamento,
pois este é o principal meio de
comunicação dos web services.
Prof. Eder Pansani

39
O protocolo HTTP
Além disso algumas arquiteturas como o
REST utiliza muitos conceitos do HTTP,
usufruindo de suas características com
objetivo de tornar a utilização de WS mais
eficiente e simples.
Prof. Eder Pansani

40
SOAP
SOAP (Simple Object Access Protocol, em
português Protocolo Simples de Acesso a
Objetos) é um protocolo para troca de
informações estruturadas em uma
plataforma descentralizada e distribuída.
Prof. Eder Pansani

41
SOAP
Ele se baseia na Linguagem de Marcação
Extensível (XML) para seu formato de
mensagem, e normalmente baseia-se em
outros protocolos da camada de aplicação,
mais notavelmente em chamada de
procedimento remoto (RPC)...
Prof. Eder Pansani
42
SOAP
... e no Protocolo de transferência de
hipertexto (HTTP), para negociação e
transmissão de mensagens.
Prof. Eder Pansani

43
SOAP
O protocolo SOAP foi uma das primeiras
abordagens para criação de web
services, porém ele possui uma
complexidade relativamente alta para
implementação, o que na prática impõe
barreiras à sua utilização.
Prof. Eder Pansani
44
REST
Devido a isso surgiu um outro
protocolo/arquitetura de comunicação e
implementação de web services, ele é
conhecido como REST (Representational
State Transfer)
Prof. Eder Pansani

45
REST
O termo foi definido no ano 2000, na tese de
doutorado de Roy Fielding e é a sigla para
Representational State Transfer: é um design de
arquitetura construído para servir aplicações em
rede. A aplicação mais comum de REST é a
própria World Wide Web, que utilizou REST como
base para o desenvolvimento do HTTP 1.1.
Prof. Eder Pansani
46
REST
De forma bastante sucinta pode-se dizer
que o REST é uma forma de implementar
e definir arquitetura de web services,
porém ele não é um padrão, desta forma
ele não é obrigatório para a criação de WS.
Prof. Eder Pansani

47
REST
Para que uma aplicação possa ser
considerada REST ela deve seguir
algumas restrições.
Dentre elas pode-se citar:
Prof. Eder Pansani

48
REST
1. Client-Server
É a restrição básica para uma aplicação

REST. O objetivo desta divisão é separar a
arquiterura e responsabilidades em dois
ambientes.
Prof. Eder Pansani

49
REST
Assim, o cliente (consumidor do serviço) 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 (provedor
do serviço) não se preocupa com tarefas como:
interface, experiência do usuário, etc. Permitindo,
assim, a evolução independente das duas
arquiteturas. Prof. Eder Pansani
50
REST
2. Stateless
Um mesmo cliente pode mandar várias

requisições para o servidor, porém, cada uma
delas devem ser independentes, ou seja, toda
requisição deve conter todas as informações
necessárias para que o servidor consiga entendê-
la e processá-la adequadamente.
Prof. Eder Pansani
51
REST
3. Cacheable
Como muitos clientes acessam um mesmo

servidor, e muitas vezes requisitando os mesmos
recursos, é necessário que estas respostas
possam ser cacheadas, evitando processamento
desnecessário e aumentando significativamente a
performance.
Prof. Eder Pansani
52
REST
4. Uniform Interface
É, basicamente, um contrato para

comunicação entre clientes e servidor. São
pequenas regras para deixar um componente
o mais genérico possível, o tornando muito
mais fácil de ser refatorado e melhorado.
Prof. Eder Pansani

53
REST
Dito isso, um dos princípios desta restrição é
que o cliente nunca deve chamar diretamente
o servidor da aplicação sem antes passar por
um intermediador, no caso, pode ser um load
balancer ou qualquer outra máquina que faça
a interface com o(s) servidor(es).
Prof. Eder Pansani

54
REST
Isso garante que o cliente se preocupe apenas
com a comunicação com o intermediador e o
intermediador fica responsável por distribuir as
requisições nos servidores. O importante é
ficar claro que criando um intermediador, a sua
estrutura fica muito mais flexível à mudanças.
Prof. Eder Pansani

55
REST
5. Layered System
A sua aplicação deve ser composta por

camadas, e estas camadas devem ser
fáceis de alterar, tanto para adicionar mais
camadas, quanto para removê-las.
Prof. Eder Pansani

56
RESTfull
E o que é RESTful?
Muita gente, quando usa diferentes URIs,

verbos HTTP e diferentes formatos de retorno,
passa a dizer que tem uma API RESTful. Tudo
isso é muito importante e faz parte, mas não é
apenas isso que compõe o RESTful.
Prof. Eder Pansani

57
RESTfull
Para uma API ser considerada RESTful ela
deve seguir estritamente as regras
definidas na arquitetura REST, além de
possuir um certo nível de coesão e
maturidade, definidos na escala chamada
de Richardson Maturity Model.
Prof. Eder Pansani
58
RESTfull
Richardson Maturity Model.
https://martinfowler.com/articles/richardsonMaturityModel.html
Prof. Eder Pansani

59
RESTfull
De forma bastante resumida, os níveis são:
Nível 0: é a ausência de qualquer regra, é

apenas a utilização do HTTP como
transporte das operações no servidor.
Normalmente se usa apenas um endpoint
(URI) e um verbo HTTP.
Prof. Eder Pansani
60
RESTfull
Nível 1: Aplicação de resources. A API é
dividida em diferentes endpoints que
apontam para um ou mais resources.
Prof. Eder Pansani

61
RESTfull
Nível 2: Implementação de verbos HTTP para
diferentes tipos de operações que deseja
executar. Uma mesma URI por aceitar mais de
um verbo HTTP, por exemplo: GET /user pode
retornar todos os usuários e POST /user
passando os atributos do usuário pode criar um
novo.
Prof. Eder Pansani
62
RESTfull
Nível 3: Um novo conceito é adicionado,
chamado: HATEOAS (Hypertext As The
Engine Of Application State). Onde a API
deve fornecer para o cliente toda a
informação necessária para interagir com a
aplicação.
Prof. Eder Pansani
63
Dúvidas?
Perguntas?
Prof. Eder Pansani


24.aula 17 - Web Services - Introdução e Conceitos

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

24.aula 17 - Web Services - Introdução e Conceitos

Hochgeladen von

Copyright:

Verfügbare Formate

1

Disciplina: Desenvolvimento Web I

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Quando você vai fazer uma requisição, é preciso que

Solicita a representação de um determinado

As informações enviadas no corpo (body) da

Remove um recurso. Deve retornar o

Prof. Eder Pansani

Atualiza um recurso na URI especificada.

Retorna informações sobre um recurso. Na

Prof. Eder Pansani

Toda requisição recebe um código de

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

Dentre elas pode-se citar:

Prof. Eder Pansani

É a restrição básica para uma aplicação

Prof. Eder Pansani

Um mesmo cliente pode mandar várias

Como muitos clientes acessam um mesmo

É, basicamente, um contrato para

Prof. Eder Pansani

Prof. Eder Pansani

Prof. Eder Pansani

A sua aplicação deve ser composta por

Prof. Eder Pansani

Muita gente, quando usa diferentes URIs,

Prof. Eder Pansani

Prof. Eder Pansani

Nível 0: é a ausência de qualquer regra, é

Prof. Eder Pansani

Prof. Eder Pansani

Das könnte Ihnen auch gefallen