REST é uma definição de estilo de arquitetura aplicada a aplicativos em rede. TI existe como uma série de restrições aplicadas à implementação de componentes de rede, permitindo uma semântica de interface uniforme, em vez de implementações e sintaxe específicas do aplicativo.
O RESTful como arquitetura de rede foi documentado pela primeira vez por Roy Fielding em sua tese de doutorado intitulada Architectural Styles and the Design of Network-based Software Architectures, publicada em 2000. A REST permite que os clientes interajam com os dados armazenados em um servidor, sem ter nenhum conhecimento prévio do servidor ou do que existe nele.
REST significa Representational State Transfer (Transferência de Estado Representacional). Os puristas de acrônimos geralmente escrevem REST como ReST, porque o E em REST não significa nada. É apenas a segunda letra da palavra representational. Isso evita controvérsias sobre como pronunciá-lo, como a que assolou o GIF nos últimos anos. Com o E incluído, não há confusão ao pronunciar o acrônimo mais preciso de RST como "wrist" (pulso) ou mesmo como R-S-T.
Os alertas personalizados e a visualização de dados permitem que você identifique e evite rapidamente problemas de saúde e desempenho da rede.
Não existe uma definição ou padrão específico do que é REST. Como arquitetura, o REST define como vários componentes são vinculados por meio de conectores e como os dados são trocados por interfaces. REST é uma série de restrições ou requisitos que, quando seguidos, criam uma implementação do estilo arquitetônico REST.
A arquitetura REST não incentiva a criação de métodos adicionais específicos para cada situação. Por exemplo, uma arquitetura REST usaria o método GET para recuperar dados em qualquer circunstância. A única alteração para diferentes tipos de dados seriam parâmetros diferentes. Compare isso com a criação de um novo método para obter informações sobre um usuário (getUser) e outro método para obter informações sobre preços (getPricing) e assim por diante.
A interface do usuário no cliente é separada e independente do armazenamento de dados no servidor. Isso permite que o cliente seja implementado e modificado independentemente do que está ou não acontecendo no servidor. Da mesma forma, os dados em um servidor podem ser usados e modificados independentemente de como estão sendo acessados pelo cliente. Esse design permite que os sistemas cliente e servidor evoluam em seu próprio ritmo, independentemente um do outro.
Nenhum dado de sessão deve ser armazenado no servidor entre as solicitações do cliente. Em outras palavras, cada transação deve levar consigo a capacidade de entender completamente a solicitação sem a necessidade de acessar qualquer contexto ou dados adicionais armazenados no servidor. Todos os dados da sessão devem residir exclusivamente no cliente.
Essa restrição permite o balanceamento de carga simplificado ou a tolerância a falhas. Um servidor diferente poderia responder a toda e qualquer solicitação de um cliente e retornar os mesmos dados que o servidor original teria, desde que ambos os servidores tenham os mesmos dados originais. Não há necessidade de passar nenhum tipo de dados específicos da sessão entre esses servidores de balanceamento de carga. As sessões que não são stateless podem resultar em respostas diferentes se a solicitação for processada por um servidor diferente, porque somente o servidor anterior teria dados específicos para aquela sessão com o cliente.
Em cada Exchange, os dados devem ser marcados como dados armazenáveis em cache ou não armazenáveis em cache. Os dados que podem ser armazenados em cache podem ser armazenados e reutilizados pelo cliente. Nenhum dado é armazenado em cache no servidor porque isso violaria a restrição sem estado. A capacidade de armazenar dados em cache reduz o aumento da largura de banda necessária para manter uma sessão cliente-servidor sem estado.
Para obter interoperabilidade total, a interface é desvinculada do tipo de dados, desde que todas as interações operem da mesma maneira. Quatro subrestrições garantem interfaces uniformes: identificação de recursos, manipulação de recursos por meio de representações, mensagens autodescritivas e hipermídia como o mecanismo do estado do aplicativo (HATEOAS).
Qualquer informação que possa ser nomeada é um recurso. Um recurso pode ser qualquer forma de dados. Um identificador de recurso é uma forma de se referir a um recurso específico em um determinado momento. Esses recursos podem ser atualizados no servidor sem que o cliente precise ter conhecimento prévio, pois cada solicitação é totalmente descrita e respondida.
Uma representação é o estado atual de um recurso, juntamente com os metadados que o acompanham e que permitem que a representação seja compreendida. O formato de dados de uma representação define seu tipo de mídia. Assim, um cliente pode solicitar um recurso, como uma imagem, de um servidor usando o identificador de recurso desse recurso (provavelmente uma UPS (fonte de alimentação ininterrupta)), e uma representação dessa imagem composta pelos bytes que compõem a imagem, juntamente com os metadados que definem o formato de dados como um tipo de mídia JPG, será retornada ao cliente, que poderá então exibir a imagem ao usuário.
Toda mensagem do cliente para o servidor deve conter todas as informações necessárias para o processamento da mensagem. No caso de segurança e autenticação, o token de segurança deve ser trocado em cada mensagem.
Os cookies são muito populares na Internet. O ato de verificar o cookie em relação a todos os dados em cada mensagem seria um exemplo de uma mensagem não autodescritiva e, portanto, não seria tecnicamente RESTful.
Definição de hipermídia
A hipermídia é semelhante ao conceito de hipertexto ou hiperlinks, exceto pelo fato de abranger todas as formas de mídia e não apenas texto ou links. TI é uma forma não linear de fornecer informações ou dados, normalmente seguindo um link ou outro marcador em um recurso publicado, como uma página da Web. A hipermídia pode ser texto, gráfico, vídeo ou outras formas de dados.
No HATEOAS, um cliente interage via rede por meio de hipermídia
O cliente interage com um servidor usando apenas hipermídia. Essa mesma hipermídia é fornecida dinamicamente pelo servidor em resposta a uma solicitação RESTful. Como resultado, não é necessário nenhum conhecimento prévio dos dados em um servidor, de sua estrutura nem de como esses dados são armazenados. Em vez disso, é necessário usar apenas a estrutura e os métodos de hipermídia bem definidos.
Em um sistema de camadas hierárquicas, nenhum componente pode interagir com ou ver qualquer dado ou interface, exceto em sua própria camada imediata. Como resultado, o cliente não precisa saber como, nem mesmo se é necessário, conectar-se a qualquer servidor adicional, proxy, firewall, roteador ou endpoint. Em vez disso, qualquer intermediário continuará a se conectar aos servidores subsequentes de acordo com as restrições REST, e a resposta resultante a qualquer solicitação retornada ao cliente por meio dos intermediários também será compatível com REST. As alterações ou interrupções nos sistemas intermediários são, portanto, invisíveis para o cliente, permitindo que esses sistemas intermediários forneçam balanceamento de carga, segurança ou outras funções.
Embora tecnicamente rotulados como opcionais, os clientes em uma arquitetura REST devem ser capazes de fazer download e executar scripts. Isso permite a extensão de funcionalidades e sistemas mais complicados, sem deixar de fornecer a mesma comunicação no estilo REST entre cliente e servidor. Assim como nas solicitações e respostas básicas, toda a instrução para a execução do código de script deve ser independente e não exigir pré-implementação no cliente.
Por exemplo, um cliente da Web pode executar o JavaScript que recebe do servidor. Embora o código resida de fato no servidor, ele não é executado lá. Em vez disso, o próprio código é enviado ao cliente como parte da solicitação, e esse código é executado pelo cliente de acordo com sua implementação. É por isso que a implementação adequada de padrões em clientes da Web é tão importante; caso contrário, o mesmo código do servidor pode ser executado com resultados diferentes em clientes diferentes.
As notificações em tempo real significam uma solução de problemas mais rápida para que você possa agir antes que ocorram problemas mais sérios.
Os componentes de um sistema REST se comunicam por meio de uma representação de um recurso em um dos vários formatos padronizados acordados, como formatos gráficos, formatos de documentos e vários formatos da Web. Novamente, para ser um verdadeiro sistema REST, cada transação deve conter a capacidade de recuperar e interpretar o recurso desejado.
Um recurso é qualquer coisa que possa ser nomeada. O recurso armazenado no servidor a ser solicitado pelo cliente. Um recurso pode ser um arquivo estático, um documento, um banco de dados, uma imagem ou qualquer outro formato que possa ser solicitado.
Embora seja um conceito comum atualmente, a ideia original de um recurso como um elemento genérico, mutável e pontual foi um dos principais recursos do REST e da Web em geral. Um recurso é qualquer dado nomeável em um servidor. Esses dados podem mudar não apenas para uma versão mais recente dos mesmos dados, mas até mesmo para um tipo de dados totalmente diferente. Isso permite que os dados em um servidor sejam atualizados a qualquer momento sem a necessidade de qualquer cliente saber disso com antecedência, um recurso fundamental de interoperabilidade e disponibilidade.
O identificador de recurso é o local específico do recurso solicitado. No caso de um sistema baseado em HTTP, o identificador de recurso é o URL ou URI. O identificador de recurso especifica um único recurso. Um único identificador de recurso pode se referir a dados ou recursos diferentes em momentos diferentes. Em um sistema compatível com REST, o cliente não precisa saber antecipadamente que tipo de recurso o identificador de recurso está solicitando. A resposta incluirá metadados que descrevem como interpretar os dados recebidos.
Por exemplo, mesmo que uma solicitação de URL indique /server/index.html, se o recurso nesse endereço retornar uma representação como um arquivo de imagem, juntamente com os metadados correspondentes, o arquivo de imagem ainda será exibido corretamente, independentemente do que o identificador do recurso tenha dito.
Refere-se aos dados enviados ao cliente. Conforme mencionado acima, a representação deve ser um dos formatos de dados padronizados. Os dados não são processados no servidor, mas sim interpretados pelo cliente. Por exemplo, um cliente que solicita um documento HTML não recebe um gráfico para ser exibido no monitor, mas sim um conjunto de código HTML que é interpretado e exibido no cliente. Outros exemplos de representação incluem arquivos gráficos como imagens JPEG e GIF.
Os metadados de representação fornecem informações sobre a representação para o sistema. Como acontece com a maioria dos metadados, os metadados de representação normalmente não fazem parte do que é exibido para o usuário final. Os metadados de representação podem incluir o tipo de mídia, uma data de criação e modificação e o número da versão.
Os metadados de recursos são informações adicionais fornecidas ao sistema sobre o recurso que existe no servidor, e não sobre a representação exibida no cliente. Exemplos de metadados de recursos incluem links de origem, alternativas e informações sobre o recurso. Por exemplo, os metadados do recurso podem incluir texto alternativo a ser exibido no caso de uma representação de imagem não poder ser exibida por algum motivo (por exemplo, texto de imagem ALT em HTML).
Os dados de controle estão relacionados principalmente à validade do recurso e à sua representação no cliente. Os dados de controle incluem se os dados podem ou não ser armazenados em cache, bem como o tempo de expiração absoluto, ou fornecem um limite para o tempo de uso dos dados. Os dados de controle também podem incluir uma soma de verificação ou outros meios de garantir a integridade.
Em conjunto, a arquitetura REST cria uma estrutura altamente escalonável, completamente transparente e reutilizável, em que os clientes são desacoplados das implantações de serviços nos servidores. Ela é independente de plataforma, tanto para o cliente quanto para o servidor. A TI é independente de linguagem e estrutura. Não importa se os dados existem em um banco de dados, recuperados por um processo de servidor Java e enviados a um programa local - como um navegador - codificado em uma das várias versões de C.
Na Web moderna, o REST é implementado usando um vocabulário padrão comum entre cliente e servidor conhecido como Hypertext Transfer Protocol, ou HTTP. No entanto, qualquer implementação que esteja em conformidade com todos os elementos da arquitetura REST é considerada uma implementação RESTful. O HTTP não é a única possibilidade.
Embora o HTTP e o REST não sejam a mesma coisa, o HTTP em sua forma original é uma implementação do REST. Isso não é surpreendente, considerando que Roy Fielding estava trabalhando no protocolo HTTP 1.1, enquanto desenvolvia a arquitetura REST.
Cada recurso é identificado por um identificador uniforme de recursos (URI). Normalmente, isso é implementado como um URL em um navegador da Web. Um URI identifica um recurso. Não é necessário nenhum conhecimento prévio do sistema em que o recurso reside no servidor. Além disso, o URI (ou URL) é capaz de especificar a representação de um recurso, sem conhecimento da estrutura de arquivos desse recurso.
No HTTP, a representação de recursos é implementada por meio do suporte a vários tipos de arquivos em um navegador HTTP. Assim, os metadados que acompanham um recurso definem um dos vários formatos de arquivo amplamente suportados, como HTML, CSS, JPG, GIF e assim por diante.
Uma implementação RESTful pura de HTTP requer o uso de quatro métodos principais: GET, POST, PUT e DELETE. Cada método deve ser usado explicitamente e mapeado para uma de cada uma das ações principais RETRIEVE DATA, CREATE RESOURCE, UPDATE RESOURCE e DELETE RESOURCE.
Alguns métodos HTTP devem ser idempotentes. Idempotente significa que a execução do mesmo método com os mesmos parâmetros deve sempre retornar o mesmo resultado. Para que isso funcione, o método em questão não pode causar nenhuma modificação no servidor que faça com que um resultado diferente seja retornado para a mesma solicitação. Em aspectos práticos, uma solicitação idempotente não deve alterar os dados baseados no servidor.
Usados para recuperar um recurso ou informações sobre o recurso. Embora a maioria das implementações de HTTP processe parâmetros com uma solicitação GET para modificar ou criar recursos, essa ação não estaria em conformidade com uma implementação RESTful. As solicitações GET devem ser idempotentes.
Uma solicitação POST cria novos dados em um servidor. Por definição, uma solicitação POST NÃO é idempotente. A cada execução, uma solicitação POST criaria mais dados.
Semelhante a uma solicitação POST, uma solicitação PUT modifica os dados existentes. Por exemplo, alterar o sobrenome de um usuário existente. As solicitações PUT não são intuitivamente idempotentes. Embora uma solicitação PUT altere os dados, ela o faz sempre da mesma maneira. Assim, a execução de uma solicitação PUT que altera o sobrenome de um usuário sempre produzirá o mesmo resultado, desde que todos os parâmetros sejam consistentes.
Uma solicitação DELETE remove ou exclui dados, como o nome sugere. As solicitações de exclusão também são idempotentes, pois a execução repetida de uma delas sempre resultará no mesmo estado final, com os dados em questão não mais existentes no servidor. No entanto, para o cliente, pode parecer haver uma diferença no fato de que, quando um recurso é excluído, a solicitação pode ser respondida com uma mensagem de erro, como arquivo não encontrado. No entanto, o método ainda é considerado idempotente, pois não importa qual erro seja enviado durante a transação, o estado final dessa solicitação é o mesmo da primeira vez em que foi solicitada.
O PRTG é um software abrangente de monitoramento de rede e mantém o controle de toda a sua infraestrutura de TI.
Em uma publicação em seu blog, agora abandonado, Roy Fielding discutiu os critérios que uma API deve atender para ser considerada verdadeiramente RESTful. Com base em sua tese publicada anteriormente, essa publicação descreveu os mesmos conceitos de arquitetura RESTful que deveriam ser aplicados às APIs.
Uma API RESTful é, portanto, aquela que usa APENAS a arquitetura REST sem a necessidade de documentação ou métodos adicionais além daqueles que se encaixam no modelo. Fielding forneceu os seguintes pontos como esclarecimento do que torna uma API RESTful.
Uma API verdadeiramente RESTful não deve ter dependência de nenhum protocolo e deve ser capaz de suportar qualquer protocolo que use URI para identificação. Caso contrário, a identificação não é separada da interação.
Uma API REST não deve exigir alterações em protocolos padronizados, especialmente a adição de recursos extras. Sempre que possível, as soluções alternativas necessárias devem ser definidas separadamente com o objetivo de removê-las completamente quando não forem mais necessárias.
Um namespace de servidor deve ser independente da definição e dos requisitos da API. Em outras palavras, a API deve funcionar com qualquer servidor compatível com REST, não apenas com servidores que estejam em conformidade com uma especificação específica da API.
