Exemplos de Webservice SOAP e REST / SOAP and REST Webservice Examples

Video Aula

https://youtu.be/a0U3p0-gyl0

Como funciona um WebService REST
A web é amplamente utilizada e reconhecida principalmente por sua arquitetura robusta, escalável e tolerante a falhas. Quem sustenta esses fatores e lhe dá todo este poder é o protocolo HTTP (o protocolo HTTP é utilizado, em regra, quando se deseja evitar que a informação transmitida entre o cliente e o servidor seja visualizada por terceiros, como, por exemplo, no caso de compras online.). Atualmente, muitas vezes necessitamos integrar aplicações em ambientes totalmente diferentes e os WebServices são uma das maneiras mais comuns e fáceis de integrar os diferentes sistemas. Este post mostrará um pouco de um modelo de WebService chamado REST.

Representational State Transfer ou somente REST, é cada vez mais usado como alternativa ao “já antigo” SOAP onde que a principal crítica a este é a burocracia, algo que REST possui em uma escala muito menor.
REST é baseado no design do protocolo HTTP, que já possui diversos mecanismos embutidos para representar recursos como código de status, representação de tipos de conteúdo, cabeçalhos, etc.

O principal nesta arquitetura são as URLs do sistema e os resources (resource é um recurso, entidade). Ele aproveita os métodos HTTP para se comunicar, que são:

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);
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.
DELETE: Remove um recurso. Deve retornar o status 204 caso não exista nenhum recurso para a URI especificada.
PUT: Atualiza um recurso na URI especificada. Caso o recurso não exista, ele pode criar um. A principal diferença entre POST e PUT é que o primeiro pode lidar não somente com recursos, mas também pode fazer processamento de informações.
Porém não existe um padrão obrigatório, pode ser implementado somente o que é necessário em seu contexto.?

--

SOAP and REST Webservice Examples

Video lessons

https://youtu.be/a0U3p0-gyl0

How a REST WebService works
The web is widely used and recognized primarily for its robust, scalable and fault tolerant architecture. Whoever supports these factors and gives them all this power is the HTTP protocol (the HTTP protocol is usually used when it is desired to avoid that the information transmitted between the client and the server is viewed by third parties, as for example in the case online shopping.). Nowadays, we often need to integrate applications into totally different environments, and WebServices are one of the most common and easy ways to integrate different systems. This post will show a bit of a WebService template called REST.

Representational State Transfer or REST only, is increasingly used as an alternative to the "old" SOAP where the main criticism of this is bureaucracy, something that REST has on a much smaller scale.
REST is based on the HTTP protocol design, which already has several built-in mechanisms to represent features like status code, representation of content types, headers, etc.

The principal in this architecture are the system URLs and the resources (resource is a resource, entity). It takes advantage of HTTP methods to communicate, which are:

GET: Requests the representation of a particular resource. It is defined as a safe method and should not be used to trigger an action (remove a user, for example);
POST: The information sent in the body of the request is used to create a new resource. It is also responsible for processing that is not directly related to a resource.
DELETE: Removes a resource. It should return status 204 if there is no resource for the specified URI.
PUT: Updates a resource in the specified URI. If the resource does not exist, it can create one. The main difference between POST and PUT is that the former can handle not only resources, but can also do information processing.
However, there is no mandatory standard, only what is necessary in its context can be implemented.

MAIS INFORMAÇÕES
Adriano José Boller
Consultor, Representante Oficial PC SOFT
Email: adrianoboller@gmail.com
Telefone: +55 (41) 99949-1800
Skype: adrianoboller
Horário: Segunda—sexta: 8h–18h
Sábados & domingos: 11h–15h