{"id":5216,"date":"2022-07-13T12:02:43","date_gmt":"2022-07-13T15:02:43","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=5216"},"modified":"2024-01-11T18:03:47","modified_gmt":"2024-01-11T21:03:47","slug":"fundamentos-para-sistemas-com-arquiteturas-rest-capitulo-9-v-2-0","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-sistemas-com-arquiteturas-rest-capitulo-9-v-2-0\/","title":{"rendered":"Fundamentos para sistemas com arquiteturas REST \/ Cap\u00edtulo 9 v 2.0"},"content":{"rendered":"APIs tem import\u00e2ncia crescente no design<\/em> de aplica\u00e7\u00f5es. Boas APIs facilitam o estabelecimento de parcerias, permitindo que sistemas se comuniquem de maneira s\u00f3lida, facilitando a automa\u00e7\u00e3o dos neg\u00f3cios.\n
\nO projeto de APIs, em consequ\u00eancia dessa import\u00e2ncia, \u00e9 atividade fundamental de arquitetura. A cria\u00e7\u00e3o de APIs intuitivas e f\u00e1ceis \u00e9 essencial. \u00c9 essencial que o arquiteto respons\u00e1vel garanta a sele\u00e7\u00e3o do estilo mais adaptado as necessidades.\n
\nDesde o in\u00edcio dos anos 2000, vem ganhando destaque APIs projetadas conforme o estilo arquitetural REST, embora, infelizmente, as implementa\u00e7\u00f5es n\u00e3o sejam, muitas vezes, “fi\u00e9is” aos princ\u00edpios estabelecidos nesse estilo.\n
\r\n

Buscando refer\u00eancias pr\u00e1ticas<\/p>\r\n<\/p>\n

Este cap\u00edtulo n\u00e3o visa ser um guia de refer\u00eancia de solu\u00e7\u00f5es REST, mas sim, fundamento para pensamento arquitetural.<\/p>\n

H\u00e1 uma pequena lista de “receitas de bolo” para problemas REST no Ap\u00eandice A<\/a>.<\/p>\n

<\/div>\n

Conceito fundamental<\/h2>\nCom frequ\u00eancia, APIs que utilizam verbos padr\u00f5es HTTP – GET, PUT, POST e DELETE – e entregam conte\u00fado em XML ou JSON s\u00e3o designadas como RESTful. Entretanto, estas caracter\u00edsticas n\u00e3o s\u00e3o suficientes para tal designa\u00e7\u00e3o.\n
\n

REST, acr\u00f4nimo para Representational State Transfer,<\/em>\u00a0\u00e9 um estilo arquitetural para sistemas hiperm\u00eddia distribu\u00eddos<\/strong>. Ele foi introduzido e definido, no ano 2000, por Roy Fielding<\/a>, em sua tese de doutorado. Trata-se de um conjunto de restri\u00e7\u00f5es arquiteturais aplicados a World Wide Web<\/em>. <\/strong><\/p>\n

Apenas sistemas desenvolvidos observando corretamente o estilo REST podem ser identificados como RESTful<\/em>.\u00a0<\/strong><\/p>\n

\r\n

Null Style<\/p>\r\n<\/p>\n

Em sua tese, Roy Fielding, defende a exist\u00eancia de duas abordagens para a elabora\u00e7\u00e3o de um\u00a0design<\/em>\u00a0arquitetural.<\/p>\n

A primeira abordagem\u00a0\u00e9 aquela onde um projeto de sistema come\u00e7a “do zero” – como que em\u00a0uma “tela em branco” – e vai sendo elaborado utilizando elementos familiares at\u00e9 que, em dado momento, satisfa\u00e7a as necessidades pretendidas.<\/p>\n

A segunda abordagem parte de um sistema “pronto”, com todos os elementos demandados para atender uma determinada necessidade j\u00e1 presentes, por\u00e9m sem restri\u00e7\u00f5es. Ent\u00e3o, restri\u00e7\u00f5es s\u00e3o aplicadas para “aparar” os elementos do sistema at\u00e9 que ele satisfa\u00e7a apenas a um conjunto de especifica\u00e7\u00f5es bem determinado. Este “ponto de partida”, sem restri\u00e7\u00f5es, \u00e9 designado por Roy Fielding como\u00a0Null Style.<\/em><\/p>\n

REST, como estilo arquitetural, tem como Null Style <\/em>a\u00a0World Wide Web.<\/em><\/strong><\/p>\n

<\/div>\nSistemas RESTful<\/em> destacam-se por terem atributos de qualidade como portabilidade, escalabilidade, visibilidade (facilidade para monitoramento), confiabilidade e desempenho percebido (responsividade). Al\u00e9m disso, tem \u00f3timo evolvability<\/em>.\n

\r\n

World Wide Web<\/p>\r\n<\/p>\n

A World Wide Web (WWW)\u00a0<\/em>\u00e9 um sistema de informa\u00e7\u00e3o onde documentos e outros recursos s\u00e3o identificados por\u00a0Uniform Resource Locators<\/em> (URLs, como https:\/\/example.com\/), interlig\u00e1veis por hiperlinks, acess\u00edveis \u200b\u200bpela Internet.<\/p>\n

Os recursos da Web<\/em> s\u00e3o transferidos por meio de implementa\u00e7\u00f5es de protocolos, como HTTP, e podem ser acessados \u200b\u200bpelos usu\u00e1rios por aplicativos navegadores \u00a0e publicados por um aplicativos servidores.<\/p>\n

<\/div>\n

Definindo “recurso”<\/h2>\n

Para entender REST \u00e9 fundamental assimilar o conceito\u00a0de “recursos”. A RFC 2396, de 1998, define “recurso” como:<\/p>\n

Um recurso pode ser qualquer coisa que tenha identidade. Os exemplos familiares incluem um documento eletr\u00f4nico, uma imagem, um servi\u00e7o (por exemplo, “previs\u00e3o do tempo de hoje para Los Angeles”) e uma cole\u00e7\u00e3o de outros recursos. Nem todos os recursos s\u00e3o “recuper\u00e1veis” pela rede; por exemplo, seres humanos, empresas e livros encadernados em uma biblioteca tamb\u00e9m podem ser considerados recursos. O recurso \u00e9 o mapeamento conceitual para uma entidade ou conjunto de entidades, n\u00e3o necessariamente a entidade que corresponde a esse mapeamento em qualquer inst\u00e2ncia espec\u00edfica no tempo. Assim, um recurso pode permanecer constante mesmo quando seu conte\u00fado — as entidades \u00e0s quais atualmente corresponde — muda ao longo do tempo, desde que o mapeamento conceitual n\u00e3o seja alterado no processo.<\/em><\/p>\n

\r\n

URI e URL<\/p>\r\n<\/p>\n

URI, acr\u00f4nimo para Uniform Resource Identificator,\u00a0<\/em>\u00e9 uma identifica\u00e7\u00e3o simples para um recurso. Enquanto isso, URL, acr\u00f4nimo para Uniform Resource Locator<\/em>,\u00a0especifica tamb\u00e9m como este recurso deve ser acessado.<\/p>\n

Todas URLs s\u00e3o URIs, mas nem toda URI \u00e9 uma URL.<\/strong><\/p>\n

<\/div>\n

Motiva\u00e7\u00f5es para REST<\/h2>\n

Embora seja comum associar REST ao desenvolvimento de APIs, suas motiv\u00e7\u00f5es s\u00e3o muito mais ambiciosas.\u00a0REST nasceu como uma abordagem para orientar a evolu\u00e7\u00e3o da arquitetura da Web!<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

Desde 1994, o estilo arquitet\u00f4nico REST tem sido usado para guiar o design e o desenvolvimento da arquitetura para a Web moderna.<\/em><\/p>\n

\r\n

Roy Fielding<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Em sua teste, Roy Fielding descreve, tamb\u00e9m, um combinado de li\u00e7\u00f5es aprendidas com a aplica\u00e7\u00e3o de REST durante a cria\u00e7\u00e3o dos padr\u00f5es da Internet para o protocolo de transfer\u00eancia de hipertexto (HTTP) e identificadores de recursos uniformes (URI), as duas especifica\u00e7\u00f5es que definem a interface gen\u00e9rica usada por todas as intera\u00e7\u00f5es de componentes na Web, como bem como da implanta\u00e7\u00e3o dessas tecnologias na forma da biblioteca cliente libwww-perl, o Projeto de servidor HTTP Apache e outras implementa\u00e7\u00f5es de padr\u00f5es de protocolo.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

A motiva\u00e7\u00e3o para desenvolver REST foi criar um modelo de arquitetura de como a Web deveria funcionar, de forma que pudesse servir como a estrutura de orienta\u00e7\u00e3o para os padr\u00f5es de protocolo da Web. O REST foi aplicado para descrever a arquitetura da Web desejada, ajudar a identificar problemas existentes, comparar solu\u00e7\u00f5es alternativas e garantir que as extens\u00f5es de protocolo n\u00e3o violem as principais restri\u00e7\u00f5es que tornam a Web bem-sucedida. Este trabalho foi feito como parte dos esfor\u00e7os do Internet Engineering Taskforce (IETF) e do World Wide Web Consortium (W3C) para definir os padr\u00f5es de arquitetura para a Web: HTTP, URI e HTML.<\/em><\/p>\n

\r\n

Roy Fielding<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Filosofia REST<\/h2>\n

O pleno entendimento de REST come\u00e7a pela interpreta\u00e7\u00e3o do que o acr\u00f4nimo significa. RE<\/strong>presentational S<\/strong>tate T<\/strong>ransfer\u00a0<\/em>literalmente expressa a intencionalidade do estilo arquitetural: transfer\u00eancia de estado atrav\u00e9s de representa\u00e7\u00f5es.<\/p>\n

As tranfer\u00eancias de estado, em sentido amplo, n\u00e3o se restringem apenas pelo conjunto de dados associados a um recurso, mas tamb\u00e9m \u00e0s opera\u00e7\u00f5es que este recurso suporta. Os diversos componentes computacionais que formam uma solu\u00e7\u00e3o REST “transferem estado” entre si, afim de preservar consist\u00eancia.<\/p>\n

A transfer\u00eancia de estado entre componentes, coloca os recursos como as “estrelas da festa”, ou seja, o centro de qualquer intera\u00e7\u00e3o. Afinal, em sentido amplo, trasnfer\u00eancias de estado acontecem pela cria\u00e7\u00e3o, modifica\u00e7\u00e3o, recupera\u00e7\u00e3o e remo\u00e7\u00e3o de recursos, orquestradas por um componente em outro remoto.<\/p>\n

O conjunto limitado e padronizado de opera\u00e7\u00f5es que transferem estado conferem a arquireturas RESTful\u00a0<\/em>simplicidade. Ou mesmo conjunto uniforme de opera\u00e7\u00f5es pode ser aplicado a qualquer recursos, de maneira consistente, atrav\u00e9s de um conjunto tamb\u00e9m bem delimitado de verbos HTTP.<\/p>\n

A transfer\u00eancia mais \u00f3bvia de estado acontece quando um componente solicita a outro a representa\u00e7\u00e3o correspondente a uma vers\u00e3o, geralmente o “momento atual”, de um recurso, utilizando para isso o verbo HTTP GET<\/em>.<\/p>\n

Menos evidentes s\u00e3o as transfer\u00eancias de estado que acontecem quando um componente envia estado – representa\u00e7\u00f5es de um recurso – para outro, geralmente com verbos HTTP POST<\/em> e HTTP PUT.<\/em><\/p>\n

Finalmente, tamb\u00e9m s\u00e3o transfer\u00eancias de estado atualiza\u00e7\u00f5es parciais de recursos, geralmente aplicadas com verbos HTTP POST<\/em> e HTTP PATCH,<\/em> bem como opera\u00e7\u00f5es de exclus\u00e3o de recursos realizadas com HTTP DELETE<\/em>.<\/p>\n

Elementos arquiteturais para REST<\/h2>\n

O estilo arquitetural REST define abstra\u00e7\u00f5es para os elementos arquitet\u00f4nicos em um sistema hiperm\u00eddia distribu\u00eddo, enquanto ignora os detalhes de implementa\u00e7\u00e3o.<\/p>\n

Sistemas RESTful <\/em>geralmente ser\u00e3o compostos por componentes, conectores que ligam esses componentes e os dados que eles utilizam.<\/p>\n

Elementos arquiteturais relacionados com “Dados”<\/h4>\n

Sistemas RESTful\u00a0<\/em>se caracterizam pela movimenta\u00e7\u00e3o dos dados atrav\u00e9s de componentes de processamento, em oposi\u00e7\u00e3o a outros estilos onde os diversos componentes operam sobre uma \u00fanica “fonte da verdade”.<\/strong> Essa caracter\u00edstica, refor\u00e7a a coes\u00e3o, eventualmente comprometendo a efici\u00eancia.<\/p>\n

Ao projetar dados, um componente “servidor” pode-se adotar uma das seguintes tr\u00eas estrat\u00e9gias:<\/p>\n

    \n
  1. renderizar os dados para uma representa\u00e7\u00e3o espec\u00edfica;<\/li>\n
  2. enviar os dados em sua representa\u00e7\u00e3o nativa, acompanhados de c\u00f3digo que realiza a renderiza\u00e7\u00e3o para uma representa\u00e7\u00e3o espec\u00edfica;<\/li>\n
  3. enviar os dados em sua representa\u00e7\u00e3o nativa, acompanhados de metadados para que o componente “cliente” adote uma estrat\u00e9gia de processamento;<\/li>\n<\/ol>\n
    \n

    S\u00e3o elementos arquiteturais relacionados com dados:<\/p>\n

O cientista ingl\u00eas Sir Timothy Berners-Lee<\/a> inventou a World Wide Web<\/em> em 1989. Ele escreveu o primeiro navegador da web em 1990 enquanto trabalhava no CERN<\/em>\u00a0(European Organization for Nuclear Research<\/em>) perto de Genebra, Su\u00ed\u00e7a. O navegador foi lan\u00e7ado fora do CERN<\/em> para outras institui\u00e7\u00f5es de pesquisa a partir de janeiro de 1991, e depois para o p\u00fablico em geral em agosto de 1991. A Web come\u00e7ou a entrar no uso di\u00e1rio em 1993, quando sites de uso geral come\u00e7aram a se tornar dispon\u00edveis.<\/p>\n