{"id":719,"date":"2023-02-28T14:32:40","date_gmt":"2023-02-28T17:32:40","guid":{"rendered":"https:\/\/vadebyte.com\/?p=719"},"modified":"2023-03-01T17:45:24","modified_gmt":"2023-03-01T20:45:24","slug":"a-evolucao-do-protocolo-http","status":"publish","type":"post","link":"https:\/\/vadebyte.com\/index.php\/2023\/02\/28\/a-evolucao-do-protocolo-http\/","title":{"rendered":"A evolu\u00e7\u00e3o do protocolo HTTP"},"content":{"rendered":"\n

Introdu\u00e7\u00e3o<\/strong><\/h2>\n\n\n\n

O protocolo HTTP est\u00e1 dispon\u00edvel oficialmente desde os anos 90 com o prop\u00f3sito de padronizar a troca de dados entre computadores pela internet.<\/p>\n\n\n\n

Criado por Tim Berners-Lee no CERN entre os anos de 1989\u20131991, o HTTP (Hypertext Transfer Protocol) \u00e9 o protocolo de comunica\u00e7\u00e3o fundamental da World Wide Web. O HTTP funciona como um protocolo de Solicita\u00e7\u00e3o-Resposta (Request-Response<\/em>) no modelo de computa\u00e7\u00e3o Cliente-Servidor (Client-Server<\/em>).<\/p>\n\n\n\n

Mas, onde o HTTP se encaixa nos modelos de redes de comunica\u00e7\u00e3o?
Como evoluiu ao longo dos anos?
Quais s\u00e3o as evolu\u00e7\u00f5es mais recentes?<\/p>\n\n\n\n

Neste artigo abordaremos de forma hol\u00edstica o protocolo HTTP. Faremos uma breve revis\u00e3o do modelos conceituais de rede OSI e TCP\/IP e da camada de aplica\u00e7\u00f5es onde se encontra o protocolo. Veremos as principais diferen\u00e7as entre as vers\u00f5es do HTTP e seu est\u00e1gio atual de evolu\u00e7\u00e3o.<\/p>\n\n\n\n

O modelo de redes<\/h2>\n\n\n\n

Do ponto de vista da engenharia, as redes normalmente consideram o modelo OSI ou o modelo TCP\/IP para definir e organizar suas opera\u00e7\u00f5es. O OSI \u00e9 um modelo conceitual de refer\u00eancia cujo objetivo \u00e9 padronizar a comunica\u00e7\u00e3o em rede e servir de base para cria\u00e7\u00e3o de outros modelos. O modelo OSI \u00e9 dividido em sete camadas, cada uma contendo fun\u00e7\u00f5es e unidades de dados de protocolo espec\u00edficas.
O modelo TCP\/IP \u00e9 uma implementa\u00e7\u00e3o pr\u00e1tica do padr\u00e3o OSI, organizado em cinco camadas, combinando camadas do modelo OSI. <\/p>\n\n\n\n

Os protocolos da camada de aplica\u00e7\u00e3o referem-se a uma camada de rede abstrata que fornece comunica\u00e7\u00e3o de ponta a ponta entre diferentes aplica\u00e7\u00f5es computacionais. A camada de aplica\u00e7\u00e3o \u00e9 a camada mais pr\u00f3xima do usu\u00e1rio, ent\u00e3o \u00e9 na camada de aplica\u00e7\u00e3o que operam, por exemplo, clientes de e-mail, streams <\/em>e navegadores.<\/p>\n\n\n\n

\"\"
Modelo OSI e TCP\/IP<\/figcaption><\/figure>\n\n\n\n

Fluxo da comunica\u00e7\u00e3o no modelo de rede TCP\/IP<\/h2>\n\n\n\n

Para ocorrer a efetiva troca de informa\u00e7\u00f5es no estilo Cliente-Servidor, a partir da camada de aplica\u00e7\u00e3o, os dados do Request <\/strong>s\u00e3o encapsulados camada a camada at\u00e9 atingir a camada f\u00edsica onde s\u00e3o transformados em sinais el\u00e9tricos, luminosos, ou outros tipos de sinais de m\u00e1quina, e entregues ao destino. Quando atingem o destino um Response <\/strong>\u00e9 enviado na dire\u00e7\u00e3o inversa at\u00e9 atingir a camada de aplica\u00e7\u00e3o solicitante.<\/p>\n\n\n\n

O HTTP \u00e9 um protocolo de aplica\u00e7\u00e3o (camada 7 do modelo OSI e camada 5 do modelo TCP\/IP) empregado para sustentar sistemas de hiperm\u00eddia distribu\u00eddos. Uma vez que opera na camada de aplica\u00e7\u00e3o, permanece independente de v\u00e1rios aspectos de rede, como endere\u00e7amento e transmiss\u00e3o.<\/p>\n\n\n\n

O HTTP depende dos protocolos TCP\/IP para funcionar. Isso significa que o HTTP \u00e9 um protocolo baseado em conex\u00e3o. Desta forma, podemos entender uma sess\u00e3o HTTP como uma sequ\u00eancia de trocas de mensagens entre um servidor conectado a um cliente. O TCP (Transmission Control Protocol) est\u00e1 localizado na camada de transporte e o IP (Internet Protocol) est\u00e1 localizado na camada de rede.<\/p>\n\n\n\n

\"\"
Como a solicita\u00e7\u00e3o \u00e9 tratada em cada camada do modelo TCP\/IP<\/figcaption><\/figure>\n\n\n\n

A evolu\u00e7\u00e3o do protocolo HTTP<\/strong><\/h2>\n\n\n\n

O HTTP surgiu como um protocolo simples para permitir a comunica\u00e7\u00e3o entre clientes e servidores pela Internet. Desde o seu lan\u00e7amento, o HTTP tornou-se um dos mais relevantes protocolos de troca de informa\u00e7\u00f5es na World Wide Web. A primeira vers\u00e3o do HTTP (0.9) era muito limitada. Esta vers\u00e3o permitia apenas que os clientes solicitassem informa\u00e7\u00f5es de um servidor usando uma \u00fanica opera\u00e7\u00e3o: GET<\/strong>.<\/p>\n\n\n\n

Desde o lan\u00e7amento da primeira vers\u00e3o o protocolo evoluiu para as vers\u00f5es HTTP\/1, HTTP\/1.1, HTTP\/2 e mais recentemente para a vers\u00e3o HTTP\/3. Nas subse\u00e7\u00f5es a seguir, exploraremos as vers\u00e3o de 1.0 a 3.0 do protocolo HTTP, com foco em suas caracter\u00edsticas particulares e novidades comparativas em rela\u00e7\u00e3o \u00e0 vers\u00e3o lan\u00e7ada anteriormente.<\/p>\n\n\n\n

HTTP\/1.0<\/strong><\/h3>\n\n\n\n

A vers\u00e3o 1.0 do HTTP foi lan\u00e7ada em 1996, cerca de cinco anos ap\u00f3s a vers\u00e3o 0.9. O HTTP\/1 foi constru\u00eddo sobre o protocolo de transporte TCP onde cada solicita\u00e7\u00e3o para o mesmo servidor requer uma conex\u00e3o TCP separada.<\/p>\n\n\n\n

\n
\n
\"\"
Conex\u00e3o baseada no handshake <\/em>TCP de tr\u00eas etapas<\/figcaption><\/figure>\n<\/div>\n\n\n\n
\n

A vers\u00e3o HTTP\/1 introduziu novos utilit\u00e1rios e novidades:<\/p>\n\n\n\n

    \n
  • Cabe\u00e7alho<\/strong>: introdu\u00e7\u00e3o do cabe\u00e7alho HTTP, permitindo a transmiss\u00e3o de metadados que tornaram o protocolo flex\u00edvel e extens\u00edvel.<\/li>\n\n\n\n
  • Versionamento<\/strong>: as requisi\u00e7\u00f5es HTTP informam explicitamente a vers\u00e3o empregada, anexando-a na linha da requisi\u00e7\u00e3o.<\/li>\n\n\n\n
  • C\u00f3digo de status<\/strong>: as respostas HTTP agora cont\u00eam um c\u00f3digo de status, permitindo que o destinat\u00e1rio verifique o status do processamento da solicita\u00e7\u00e3o (com \u00eaxito ou com falha).<\/li>\n\n\n\n
  • Content-Type<\/em>\/Tipo de conte\u00fado<\/strong>: gra\u00e7as ao cabe\u00e7alho HTTP, e especificamente ao campo Content-Type, o HTTP pode transmitir outros tipos de documentos al\u00e9m dos arquivos HTML simples.<\/li>\n\n\n\n
  • Novos m\u00e9todos<\/strong>: al\u00e9m de GET, o HTTP 1.0 introduziu dois novos m\u00e9todos (POST e HEAD).<\/li>\n<\/ul>\n<\/div>\n<\/div>\n\n\n\n

    HTTP\/1.1<\/strong><\/h3>\n\n\n\n

    A vers\u00e3o 1.1 do HTTP foi lan\u00e7ada em 1997, apenas um ano ap\u00f3s a vers\u00e3o 1.0 anterior. O HTTP 1.1 \u00e9 um aprimoramento do HTTP 1.0, fornecendo v\u00e1rias melhorias e extens\u00f5es. <\/p>\n\n\n\n

    Entre as melhorias mais relevantes introduzidas pelo HTTP\/1.1 est\u00e3o:<\/p>\n\n\n\n

      \n
    • Cabe\u00e7alho do host<\/strong>:<\/strong> no HTTP 1.1, o cabe\u00e7alho do host \u00e9 mandat\u00f3rio. O cabe\u00e7alho do host \u00e9 especialmente importante para rotear mensagens atrav\u00e9s de servidores proxy, permitindo distinguir dom\u00ednios que apontam para o mesmo IP.<\/li>\n\n\n\n
    • Conex\u00f5es persistentes<\/strong>:<\/strong> no HTTP 1.0, cada par solicita\u00e7\u00e3o\/resposta requer a abertura de uma nova conex\u00e3o TCP. No HTTP 1.1 \u00e9 poss\u00edvel executar v\u00e1rias requisi\u00e7\u00f5es usando uma \u00fanica conex\u00e3o.<\/li>\n\n\n\n
    • Status de continua\u00e7\u00e3o<\/strong>:<\/strong> para evitar que os servidores recusem solicita\u00e7\u00f5es n\u00e3o process\u00e1veis, os clientes podem primeiro enviar apenas os cabe\u00e7alhos da solicita\u00e7\u00e3o e verificar se recebem um c\u00f3digo de status de continua\u00e7\u00e3o (c\u00f3digos de n\u00edvel 100).<\/li>\n\n\n\n
    • Novos m\u00e9todos<\/strong>:<\/strong> al\u00e9m dos m\u00e9todos j\u00e1 dispon\u00edveis do HTTP 1.0, a vers\u00e3o 1.1 adicionou seis m\u00e9todos extras: PUT, PATCH, DELETE, CONNECT, TRACE e OPTIONS.<\/li>\n\n\n\n
    • Compacta\u00e7\u00e3o e Descompacta\u00e7\u00e3o<\/strong>.<\/li>\n\n\n\n
    • Suporte a v\u00e1rios idiomas<\/strong>.<\/li>\n\n\n\n
    • Transfer\u00eancias de intervalo de bytes<\/strong>.<\/li>\n<\/ul>\n\n\n\n

      O mecanismo de Conex\u00f5es Persistentes ou keep-alive<\/em><\/strong> reduz a lat\u00eancia da solicita\u00e7\u00e3o uma vez que o cliente n\u00e3o precisa iniciar o handshake TCP de tr\u00eas etapas que \u00e9 bastante oneroso em cada solicita\u00e7\u00e3o.<\/p>\n\n\n\n

      \"\"
      Conex\u00f5es persistentes reduzem a lat\u00eancia da solicita\u00e7\u00e3o<\/figcaption><\/figure>\n\n\n\n

      O HTTP\/1.1 tamb\u00e9m adicionou o conceito de Funil HTTP ou HTTP pipelining<\/em><\/strong>. O HTTP pipelining<\/em> permite que o cliente envie v\u00e1rias solicita\u00e7\u00f5es antes de esperar cada resposta. No entanto, a resposta deve ser recebida na mesma ordem em que foram feitas as solicita\u00e7\u00f5es.<\/p>\n\n\n\n

      \"\"
      HTTP<\/em> pipelining <\/em><\/figcaption><\/figure>\n\n\n\n

      O conceito de HTTP pipelining<\/em> <\/strong> se mostrou bastante complicado de implementar corretamente e muitos servidores de proxy intermedi\u00e1rios n\u00e3o lidavam com o  HTTP pipelining <\/em>adequadamente. Eventualmente seu suporte acabou sendo removido de muitos navegadores.<\/p>\n\n\n\n

      O HTTP pipelining tamb\u00e9m sofre de um problema chamado bloqueio de cabe\u00e7a de linha ou head-of-line-blocking<\/em>. Com o head-of-line-blocking<\/em>, solicita\u00e7\u00f5es subsequentes na mesma conex\u00e3o devem aguardar a conclus\u00e3o das solicita\u00e7\u00f5es anteriores. Se uma solicita\u00e7\u00e3o for bloqueada por qualquer motivo, como perda de pacote, todas as solicita\u00e7\u00f5es subsequentes na mesma conex\u00e3o tamb\u00e9m ser\u00e3o afetadas.<\/p>\n\n\n\n

      \"\"
      head-of-line-blocking<\/figcaption><\/figure>\n\n\n\n

      Para manter o desempenho de carregamento em um n\u00edvel aceit\u00e1vel, os navegadores normalmente mant\u00eam m\u00faltiplas conex\u00f5es TCP para o mesmo servidor e enviam solicita\u00e7\u00f5es em paralelo.<\/p>\n\n\n\n

      HTTP\/2<\/strong><\/h3>\n\n\n\n

      O HTTP vers\u00e3o 2.0 foi lan\u00e7ado oficialmente em 2015, cerca de dezoito anos ap\u00f3s o HTTP 1.1. O HTTP 2.0 se concentrou em aumentar o desempenho do protocolo, e para isso, implementou recursos para melhorar conex\u00f5es e a troca de dados. Podemos ver o HTTP 2.0 como um patch <\/em>de melhorias para resolver os problemas e limita\u00e7\u00f5es das \u00faltimas vers\u00f5es do HTTP. Vejamos alguns recursos implementados pelo HTTP\/2.<\/p>\n\n\n\n

        \n
      • Multiplexa\u00e7\u00e3o de solicita\u00e7\u00e3o:<\/strong> HTTP 1.1 \u00e9 um protocolo sequencial. Assim, podemos enviar uma \u00fanica solicita\u00e7\u00e3o por vez. O HTTP 2.0, por sua vez, permite enviar requisi\u00e7\u00f5es e receber respostas de forma ass\u00edncrona. Dessa forma, podemos fazer v\u00e1rias solicita\u00e7\u00f5es ao mesmo tempo usando uma \u00fanica conex\u00e3o<\/li>\n\n\n\n
      • Prioriza\u00e7\u00e3o de solicita\u00e7\u00f5es:<\/strong><\/strong> com o HTTP 2.0, podemos definir uma prioriza\u00e7\u00e3o num\u00e9rica em um lote de solicita\u00e7\u00f5es. Assim, podemos ser expl\u00edcitos em que ordem esperamos as respostas, como obter um CSS de p\u00e1gina da Web antes de seus arquivos JS.<\/li>\n\n\n\n
      • Compacta\u00e7\u00e3o autom\u00e1tica:<\/strong><\/strong> na vers\u00e3o anterior do HTTP (1.1), devemos exigir explicitamente a compacta\u00e7\u00e3o de solicita\u00e7\u00f5es e respostas. HTTP 2.0, no entanto, executa uma compacta\u00e7\u00e3o GZip automaticamente.<\/li>\n\n\n\n
      • Redefini\u00e7\u00e3o de conex\u00e3o:<\/strong><\/strong> funcionalidade que permite fechar uma conex\u00e3o entre um servidor e um cliente por algum motivo, abrindo imediatamente uma nova.<\/li>\n\n\n\n
      • Server push:<\/strong><\/strong> para evitar que um servidor receba muitos pedidos, o HTTP 2.0 introduziu uma funcionalidade de server push. Com isso, o servidor tenta prever os recursos que ser\u00e3o solicitados em breve. Portanto, o servidor envia proativamente esses recursos para o cache do cliente.<\/li>\n\n\n\n
      • Protocolo Bin\u00e1rio:<\/strong> o HTTP 2.0 tornou-se um protocolo bin\u00e1rio, substituindo as vers\u00f5es anteriores de texto simples do HTTP.<\/li>\n<\/ul>\n\n\n\n

        O HTTP\/2 apresentou o conceito de fluxos de dados HTTP ou HTTP streams<\/em>, onde v\u00e1rios fluxos de dados podem ser enviados para o mesmo servidor em uma \u00fanica conex\u00e3o TCP possibilitando a Multiplexa\u00e7\u00e3o de solicita\u00e7\u00e3o<\/strong>. Ao contr\u00e1rio do HTTP pipelining<\/em> da vers\u00e3o 1.1, cada fluxo de dados \u00e9 independente um do outro e n\u00e3o precisa ser enviado ou recebido na mesma ordem. O HTTP\/2 resolve o problema de head-of-line-blocking na camada de aplica\u00e7\u00f5es, mas o problema ainda persiste na camada de transporte com o uso do protocolo TCP.<\/p>\n\n\n\n

        \"\"
        HTTP streams com reutiliza\u00e7\u00e3o de conex\u00f5es e multiplexa\u00e7\u00e3o de solicita\u00e7\u00e3o<\/figcaption><\/figure>\n\n\n\n

        Com a introdu\u00e7\u00e3o do server push <\/strong>os servidores enviam proativamente atualiza\u00e7\u00f5es aos clientes de depend\u00eancias utilizadas por recursos originalmente solicitados sempre que novos dados estiverem dispon\u00edveis, sem exigir que um cliente fa\u00e7a solicita\u00e7\u00f5es adicionais.<\/p>\n\n\n\n

        \"\"
        Com server push, o servidor envia proativamente recursos dependentes<\/em> para o cache do cliente <\/figcaption><\/figure>\n\n\n\n

        HTTP\/3<\/strong><\/strong><\/h3>\n\n\n\n

        HTTP 3.0 foi iniciado em 2018 teve seu primeiro rascunho foi liberado em 2020 e foi publicado recentemente em junho de 2022.<\/p>\n\n\n\n

        A principal diferen\u00e7a entre HTTP 2.0 e HTTP 3.0 \u00e9 o protocolo da camada de transporte empregado. No HTTP 2.0, temos conex\u00f5es TCP com ou n\u00e3o TLS (HTTPS e HTTP). O HTTP 3.0, por sua vez, \u00e9 projetado sobre QUIC (Quick UDP Internet Connections).<\/p>\n\n\n\n

        QUIC, \u00e9 um protocolo de camada de transporte com multiplexa\u00e7\u00e3o nativa e criptografia integrada. O QUIC fornece um r\u00e1pido processo de handshake, al\u00e9m de ser capaz de mitigar problemas de lat\u00eancia em conex\u00f5es lentas e com perdas. Al\u00e9m dos potenciais benef\u00edcios herdados do QUIC, outra caracter\u00edstica relevante do HTTP 3.0 \u00e9 que ele sempre cria conex\u00f5es criptografadas. Portanto, \u00e9 semelhante a sempre empregar HTTPS no HTTP 2.0 atual. O QUIC elimina o bloqueio de head-of-line-blocking<\/em> <\/strong>na camada de transporte.<\/p>\n\n\n\n

        \"\"
        QUIC sobre UDP<\/figcaption><\/figure>\n\n\n\n

        O QUIC foi projetado para dispositivos m\u00f3veis que fazem uso intenso da internet. As pessoas que carregam smartphones mudam constantemente de uma rede para outra enquanto se movem durante seu dia. Com o TCP, a mudan\u00e7a de uma rede para outra \u00e9 relativamente lenta. QUIC implementa um conceito chamado ID de conex\u00e3o ou QUIC Connection ID<\/em>, permitindo que as conex\u00f5es se movam entre endere\u00e7os IP e interfaces de rede de forma r\u00e1pida e confi\u00e1vel.<\/p>\n\n\n\n

        \"\"
        QUIC Connection ID permite mudan\u00e7a r\u00e1pida entre redes<\/figcaption><\/figure>\n\n\n\n

        Resumo<\/strong><\/strong><\/h2>\n\n\n\n

        O HTTP \u00e9 um protocolo extremamente relevante e suporta um grande n\u00famero de sistemas e em execu\u00e7\u00e3o na internet. Lan\u00e7ado em 1991, passou por v\u00e1rias evolu\u00e7\u00f5es e melhorias desde sua vers\u00e3o HTTP\/0.9 inicial at\u00e9 a vers\u00e3o mais atual HTTP\/3.<\/p>\n\n\n\n

        Exemplos das melhorias implementadas pelo HTTP foram o cabe\u00e7alho do protocolo (1.0), c\u00f3digos de status (1.0), novos m\u00e9todos POST (1.0), HEAD (1.0), conex\u00f5es persistentes (1.1), novos m\u00e9todos PUT (1.1), PATCH (1.1), DELETE (1.1), CONNECT (1.1 ), TRACE (1.1) e OPTIONS (1.1), multiplexa\u00e7\u00e3o de solicita\u00e7\u00e3o (2.0) e push do servidor (2.0).<\/p>\n\n\n\n

        No HTTP 3.0, a principal novidade \u00e9 a substitui\u00e7\u00e3o do protocolo TCP pelo protocolo QUIC na camada de transporte. Ao substituir o TCP pelo QUIC, os desenvolvedores de HTTP esperam, entre outras melhorias, obter criptografia nativa e padr\u00e3o (n\u00e3o h\u00e1 mais HTTP e HTTPS, toda comunica\u00e7\u00e3o HTTP \u00e9 criptografada) e r\u00e1pido estabelecimento de conex\u00f5es.<\/p>\n\n\n\n

        Veja o resumo gr\u00e1fico abaixo sobre a evolu\u00e7\u00e3o das vers\u00f5es do protocolo HTTP.<\/p>\n\n\n\n

        \"\"
        Resumo da evolu\u00e7\u00e3o HTTP por funcionalidade<\/figcaption><\/figure>\n\n\n\n

        Conclus\u00e3o<\/h2>\n\n\n\n

        Neste artigo, aprendemos um pouquinho sobre HTTP. Focamos em explorar a evolu\u00e7\u00e3o do protocolo HTTP atrav\u00e9s de suas diferentes vers\u00f5es. Inicialmente, estudamos defini\u00e7\u00f5es gerais de modelos de conceituais de redes e protocolos da camada de aplica\u00e7\u00e3o. O HTTP iniciou como um protocolo de texto simples que permitia a navega\u00e7\u00e3o na web em suas primeiras vers\u00f5es e se tornou um poderoso protocolo bin\u00e1rio que suporta diferentes sistemas. Assim, podemos concluir que o HTTP desempenha um papel crucial na atual World Wide Web.<\/p>\n","protected":false},"excerpt":{"rendered":"

        O protocolo HTTP est\u00e1 dispon\u00edvel oficialmente desde os anos 90 com o prop\u00f3sito de padronizar a troca de dados entre computadores pela internet.<\/p>\n","protected":false},"author":1,"featured_media":747,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"[\"content\",\"tags\"]","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","_themeisle_gutenberg_block_has_review":false,"footnotes":""},"categories":[8],"tags":[9,10,12,13,11],"class_list":["post-719","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-desenho-de-sistemas","tag-desenho-de-sistemas","tag-http","tag-internet","tag-protocolos","tag-redes"],"_links":{"self":[{"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/posts\/719","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/comments?post=719"}],"version-history":[{"count":1,"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/posts\/719\/revisions"}],"predecessor-version":[{"id":746,"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/posts\/719\/revisions\/746"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/media\/747"}],"wp:attachment":[{"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/media?parent=719"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/categories?post=719"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/tags?post=719"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}