{"id":1941,"date":"2021-06-07T00:15:33","date_gmt":"2021-06-07T03:15:33","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=1941"},"modified":"2024-01-11T18:02:49","modified_gmt":"2024-01-11T21:02:49","slug":"fundamentos-para-sistemas-com-arquiteturas-rest-capitulo-9-v-1-0","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-sistemas-com-arquiteturas-rest-capitulo-9-v-1-0\/","title":{"rendered":"Fundamentos para sistemas com arquiteturas REST \/ Cap\u00edtulo 9 v 1.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

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

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-4, quando sites de uso geral come\u00e7aram a se tornar dispon\u00edveis.<\/p>\n