{"id":353,"date":"2023-02-06T12:24:44","date_gmt":"2023-02-06T15:24:44","guid":{"rendered":"https:\/\/demosites.io\/web-agency-gb\/?p=353"},"modified":"2023-03-01T17:25:45","modified_gmt":"2023-03-01T20:25:45","slug":"what-is-the-progressive-web-app-pwa-and-how-it-works","status":"publish","type":"post","link":"https:\/\/vadebyte.com\/index.php\/2023\/02\/06\/what-is-the-progressive-web-app-pwa-and-how-it-works\/","title":{"rendered":"Por que API RESTful \u00e9 t\u00e3o utilizado?"},"content":{"rendered":"\n

O que \u00e9 API?<\/strong><\/h2>\n\n\n\n
\n
\n

A<\/strong>pplication P<\/strong>rogramming I<\/strong>nterface (API<\/strong>) ou Interface de Programa\u00e7\u00e3o de Aplica\u00e7\u00f5es \u00e9 um conjunto de rotinas e padr\u00f5es disponibilizados por uma aplica\u00e7\u00e3o para que outras aplica\u00e7\u00f5es possam consumir seus recursos.
API \u00e9 respons\u00e1vel por estabelecer comunica\u00e7\u00e3o entre dois servi\u00e7os e intermediar a troca de informa\u00e7\u00f5es.<\/p>\n<\/div>\n\n\n\n

\n
\"\"
Contexto de uma API<\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n

API REST<\/h2>\n\n\n\n

O padr\u00e3o de API mais comumente utilizado pela maioria dos dispositivos m\u00f3veis e aplicativos da web para se comunicar com os servidores \u00e9 chamado de REST<\/strong> ou RE<\/strong>presentational S<\/strong>tate T<\/strong>ransfer.
REST <\/strong>\u00e9 um conjunto de princ\u00edpios e restri\u00e7\u00f5es necess\u00e1rios para a cria\u00e7\u00e3o de um projeto com interfaces bem definidas que devem ser consideradas na troca de informa\u00e7\u00f5es entre servi\u00e7os da Web.
Esse estilo arquitet\u00f4nico foi definido pelo cientista da computa\u00e7\u00e3o Roy Fielding que anteriormente j\u00e1 havia trabalhado na cria\u00e7\u00e3o do protocolo HTTP <\/strong>e defini\u00e7\u00f5es da URI<\/strong>.<\/p>\n\n\n\n

APIs REST que estiverem em conformidade com as seis restri\u00e7\u00f5es do padr\u00e3o REST ser\u00e3o consideradas APIs RESTful:<\/p>\n\n\n\n

    \n
  • Arquitetura cliente-servidor:<\/strong> o modelo de arquitetura REST \u00e9 composta por clientes, servidores e recursos. As requisi\u00e7\u00f5es s\u00e3o feitas via protocolo HTTP com independ\u00eancia entre o cliente e o servidor.<\/li>\n\n\n\n
  • Sem monitora\u00e7\u00e3o de estado (Stateless):<\/strong> nenhum conte\u00fado do cliente \u00e9 armazenado no servidor entre as requisi\u00e7\u00f5es. Cada requisi\u00e7\u00e3o ou REQUEST que o cliente faz para o servidor deve conter todas as informa\u00e7\u00f5es necess\u00e1rias para o servidor entender e gerar um RESPONSE de forma completa.<\/li>\n\n\n\n
  • Capacidade de cache:<\/strong> o armazenamento em cache pode eliminar algumas intera\u00e7\u00f5es entre o cliente e o servidor e devem ser expl\u00edcitas ao dizer se a requisi\u00e7\u00e3o poder\u00e1 ser armazenada pelo cliente.<\/li>\n\n\n\n
  • Sistema em camadas:<\/strong> O cliente acessa o endpoint de um recurso, sem precisar saber da complexidade necess\u00e1ria para o servidor responder a requisi\u00e7\u00e3o ou quais outras camadas o servidor estar\u00e1 lidando para atender \u00e0 requisi\u00e7\u00e3o. Essas camadas podem oferecer recursos extras, como balanceamento de carga, caches compartilhados ou seguran\u00e7a.<\/li>\n\n\n\n
  • C\u00f3digo sob demanda (opcional):<\/strong> os servidores podem ampliar a funcionalidade de um cliente por meio da transfer\u00eancia de c\u00f3digos execut\u00e1veis. Apesar deste recurso ser pouco utilizado existe a possibilidade da aplica\u00e7\u00e3o obter c\u00f3digos e executar no lado do cliente.<\/li>\n\n\n\n
  • Interface uniforme:<\/strong> Uma interface uniforme permite o desenvolvimento independente da aplica\u00e7\u00e3o entre usu\u00e1rio e servidor. Oferece uma comunica\u00e7\u00e3o padronizada entre o usu\u00e1rio e o software. A manipula\u00e7\u00e3o de recursos atrav\u00e9s de representa\u00e7\u00f5es (como JSON ou XML) \u00e9 uma das condi\u00e7\u00f5es para o desenvolvimento de uma interface uniforme. <\/li>\n<\/ul>\n\n\n\n

    Efeitos arquiteturais REST<\/strong><\/h2>\n\n\n\n
    \n
    \n
    \"\"
    Influ\u00eancia do REST na arquitetura de aplica\u00e7\u00f5es<\/figcaption><\/figure>\n\n\n\n

    Os princ\u00edpios e restri\u00e7\u00f5es implementados no estilo arquitet\u00f4nico REST afetam importantes propriedades arquitet\u00f4nicas de aplica\u00e7\u00f5es, incluindo:<\/p>\n\n\n\n

      \n
    • Performance <\/strong>em intera\u00e7\u00f5es de componentes que podem ser o fator determinante no desempenho percebido pelo usu\u00e1rio e na efici\u00eancia da rede<\/li>\n<\/ul>\n<\/div>\n\n\n\n
      \n
        \n
      • Escalabilidade <\/strong>permitindo o suporte de um grande n\u00famero de componentes e intera\u00e7\u00f5es entre componentes<\/li>\n\n\n\n
      • Simplicidade <\/strong>de uma interface uniforme<\/li>\n\n\n\n
      • Capacidade de modifica\u00e7\u00e3o<\/strong> de componentes para atender \u00e0s necessidades de mudan\u00e7a – mesmo enquanto o aplicativo est\u00e1 em execu\u00e7\u00e3o<\/li>\n\n\n\n
      • Visibilidade da comunica\u00e7\u00e3o<\/strong> entre componentes pelos agentes de servi\u00e7o<\/li>\n\n\n\n
      • Portabilidade<\/strong> de componentes movimentando o c\u00f3digo do programa e os dados<\/li>\n\n\n\n
      • Confiabilidade<\/strong> na resist\u00eancia \u00e0 falha no n\u00edvel do sistema na presen\u00e7a de falhas em componentes, conectores ou dados<\/li>\n<\/ul>\n<\/div>\n<\/div>\n\n\n\n

        Organiza\u00e7\u00e3o dos recursos<\/strong><\/h2>\n\n\n\n

        Uma API RESTful organiza recursos em um conjunto \u00fanico de URIs<\/strong> (U<\/strong>niform R<\/strong>esource I<\/strong>dentificator).
        URI \u00e9 uma sequ\u00eancia \u00fanica de caracteres que identifica um recurso l\u00f3gico ou f\u00edsico usado por tecnologias da web, podem ser usados para identificar qualquer coisa, incluindo objetos do mundo real, como pessoas e lugares, conceitos ou recursos de informa\u00e7\u00e3o, como p\u00e1ginas da web, servidores e bancos de dados.<\/p>\n\n\n\n

        \"\"
        Organiza\u00e7\u00e3o de recursos em URIs<\/figcaption><\/figure>\n\n\n\n

        Os recursos devem ser agrupados por substantivos e n\u00e3o por verbos. A explica\u00e7\u00e3o para isso \u00e9 que o URI deve referir-se a um recurso que \u00e9 uma coisa (ou substantivo) em vez de se referir a uma a\u00e7\u00e3o (ou verbo) pois substantivos t\u00eam propriedades que os verbos n\u00e3o possuem \u2013 semelhantes aos atributos nos recursos.
        Dessa forma um recurso de API para obter todos os pedidos deveria se chamar \/pedidos<\/strong> e n\u00e3o \/obterTodosPedidos<\/strong>.<\/p>\n\n\n\n

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

        Um cliente interage com um recurso fazendo uma requisi\u00e7\u00e3o ao endere\u00e7o HTTP – endpoint do recurso.
        A requisi\u00e7\u00e3o ou REQUEST<\/strong> cont\u00e9m o URI do recurso que gostar\u00edamos de acessar e \u00e9 precedida por um verbo HTTP que informa ao servidor o que queremos fazer com o recurso.<\/p>\n\n\n\n

        \n
        \n
        \"\"
        Estrutura da requisi\u00e7\u00e3o<\/figcaption><\/figure>\n\n\n\n
        \"\"
        CRUD<\/figcaption><\/figure>\n\n\n\n
        \"\"
        Elementos da requisi\u00e7\u00e3o<\/figcaption><\/figure>\n<\/div>\n\n\n\n
        \n

        Os verbos mais utilizados numa API RESTful s\u00e3o o POST<\/strong>, GET<\/strong>, PUT<\/strong>, DELETE <\/strong>eles permitem a implementa\u00e7\u00e3o das opera\u00e7\u00f5es b\u00e1sicas de CRUD<\/strong>, essenciais em praticamente todas as aplica\u00e7\u00f5es.<\/p>\n\n\n\n

          \n
        • Um verbo do tipo POST <\/strong>significa que queremos criar um novo recurso<\/li>\n\n\n\n
        • Um GET <\/strong>significa que queremos ler os dados sobre um recurso existente<\/li>\n\n\n\n
        • PUT <\/strong>\u00e9 para atualizar um recurso existente<\/li>\n\n\n\n
        • e DELETE <\/strong>\u00e9 para remover um recurso existente<\/li>\n<\/ul>\n\n\n\n

          Outros verbos HTTP importantes mas menos utilizados s\u00e3o:<\/p>\n\n\n\n

            \n
          • PATCH <\/strong>utilizado para atualizar partes de um recurso e n\u00e3o o recurso como um todo<\/li>\n\n\n\n
          • OPTIONS <\/strong>retorna os m\u00e9todos HTTP suportados pelo servidor para a URI especificada<\/li>\n\n\n\n
          • TRACE <\/strong>devolve a mesma requisi\u00e7\u00e3o enviada verificando se houve mudan\u00e7as e\/ou adi\u00e7\u00f5es feitas por servidores intermedi\u00e1rios<\/li>\n\n\n\n
          • CONNECT <\/strong>converte a requisi\u00e7\u00e3o de conex\u00e3o para um t\u00fanel TCP\/IP transparente, geralmente para facilitar a comunica\u00e7\u00e3o criptografada com SSL (ou HTTPS) atrav\u00e9s de um proxy HTTP n\u00e3o criptografado<\/li>\n<\/ul>\n<\/div>\n<\/div>\n\n\n\n

            No corpo de uma requisi\u00e7\u00e3o h\u00e1 um elemento opcional que chamamos de HTTP Request Body. O Request Body pode conter dados personalizados da requisi\u00e7\u00e3o – payload – geralmente codificado no formato JSON, mas podendo ser codificado em outros formatos como por exemplo XML, HTML ou TEXTO.<\/p>\n\n\n\n

            Resposta<\/strong><\/h2>\n\n\n\n

            O servidor recebe a requisi\u00e7\u00e3o, processa-a, e formata o resultado em uma resposta ou RESPONSE<\/strong>.
            A primeira linha da resposta cont\u00e9m o c\u00f3digo de status HTTP para dizer ao cliente o que aconteceu com a requisi\u00e7\u00e3o.<\/p>\n\n\n\n

            \n
            \n
            \"\"
            Estrutura da resposta<\/figcaption><\/figure>\n\n\n\n
            \"\"
            N\u00edveis de c\u00f3digos HTTP<\/figcaption><\/figure>\n<\/div>\n\n\n\n
            \n

            Uma API RESTful bem implementada retorna os c\u00f3digos de status HTTP adequados.<\/p>\n\n\n\n

              \n
            • Os c\u00f3digos de n\u00edvel 100<\/strong> indicam que a requisi\u00e7\u00e3o foi recebida e entendida. Essa resposta \u00e9 despachada provisoriamente, enquanto o processamento da requisi\u00e7\u00e3o continua.<\/li>\n\n\n\n
            • Os c\u00f3digos de n\u00edvel 200<\/strong> indicam que a requisi\u00e7\u00e3o foi bem-sucedida.<\/li>\n\n\n\n
            • Os c\u00f3digos de n\u00edvel 300<\/strong> indicam que o cliente deve tomar medidas adicionais para completar a requisi\u00e7\u00e3o.<\/li>\n\n\n\n
            • Os c\u00f3digos de n\u00edvel 400<\/strong> indicam que algo estava errado com a nossa requisi\u00e7\u00e3o.
              Por exemplo: A requisi\u00e7\u00e3o possui sintaxe incorreta<\/li>\n\n\n\n
            • Os c\u00f3digos de n\u00edvel 500<\/strong> indicam que algo deu errado no lado do servidor.
              Por exemplo: O servi\u00e7o n\u00e3o estava dispon\u00edvel.<\/li>\n<\/ul>\n<\/div>\n<\/div>\n\n\n\n

              O corpo de resposta ou HTTP Response Body \u00e9 opcional e pode conter os dados personalizados de resposta – payload – geralmente em formato JSON – tamb\u00e9m podendo ser codificado nos formatos XML, HTML ou TEXTO.<\/p>\n\n\n\n

              Idempot\u00eancia<\/strong><\/h2>\n\n\n\n

              Um cliente poderia optar por tentar efetuar novamente uma requisi\u00e7\u00e3o que tenha falhado, quando por exemplo retorna um c\u00f3digo de status de n\u00edvel 500. Dizemos “poderia optar por tentar efetuar novamente<\/strong>” porque algumas a\u00e7\u00f5es n\u00e3o s\u00e3o idempotentes <\/strong>ou possuem peculiaridades que requerem cuidado extra ao tentar novamente.
              Quando uma API \u00e9 idempotente significa que ao fazermos v\u00e1rias requisi\u00e7\u00f5es id\u00eanticas ao mesmo recurso, teremos o mesmo resultado como resposta como se estiv\u00e9ssemos fazendo uma \u00fanica requisi\u00e7\u00e3o. Em outras palavras, um m\u00e9todo idempotente n\u00e3o deveria possuir nenhum efeito colateral (exceto para manter estat\u00edsticas).<\/p>\n\n\n\n

              \n
              \n

              Os verbos HTTP implementados corretamente t\u00eam diferentes comportamentos em rela\u00e7\u00e3o \u00e0 Idempot\u00eancia assim como em rela\u00e7\u00e3o a outros princ\u00edpios.<\/p>\n\n\n\n

                \n
              • O POST<\/strong> n\u00e3o \u00e9 idempotente uma vez que cada nova requisi\u00e7\u00e3o criar\u00e1 uma nova inst\u00e2ncia do recurso. Exemplo: um novo registro ser\u00e1 criado no banco de dados a cada requisi\u00e7\u00e3o. No entanto pode ser armazenado em cache para reutiliza\u00e7\u00e3o e melhoria de performance.<\/li>\n\n\n\n
              • O GET<\/strong> \u00e9 por natureza idempotente, seguro e armazen\u00e1vel em cache.<\/li>\n\n\n\n
              • O PUT <\/strong>\u00e9 idempotente e seguro.<\/li>\n\n\n\n
              • O DELETE <\/strong>\u00e9 idempotente e seguro. Para ser idempotente, somente o estado atual do servidor deve ser considerado, o c\u00f3digo de status retornado por cada requisi\u00e7\u00e3o pode variar: a primeira chamada de um DELETE provavelmente retornar o c\u00f3digo HTTP 200 (Sucesso), chamadas sucessivas provavelmente retornar\u00e3o o c\u00f3digo HTTP 404 (N\u00e3o encontrado).<\/li>\n<\/ul>\n<\/div>\n\n\n\n
                \n
                \"\"
                Resposta com erro HTTP 500<\/figcaption><\/figure>\n\n\n\n
                <\/div>\n\n\n\n
                \"\"
                Caracter\u00edsticas dos verbos HTTP<\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n

                Stateless<\/strong><\/strong><\/h2>\n\n\n\n

                Uma implementa\u00e7\u00e3o REST \u00e9 por defini\u00e7\u00e3o STATELESS<\/strong> ou seja n\u00e3o preserva o estado das transa\u00e7\u00f5es.
                Isso significa que as duas partes na comunica\u00e7\u00e3o – o cliente e o servidor – n\u00e3o precisam armazenar nenhuma informa\u00e7\u00e3o um do outro, e cada ciclo de requisi\u00e7\u00e3o e resposta (REQUEST \/ RESPONSE<\/strong>) \u00e9 completamente independente.
                [*] Isso permite a cria\u00e7\u00e3o de aplica\u00e7\u00f5es web mais confi\u00e1veis e mais f\u00e1ceis de escalar.<\/strong><\/p>\n\n\n\n

                \"\"
                Stateless<\/figcaption><\/figure>\n\n\n\n

                Boas pr\u00e1ticas<\/strong><\/strong><\/h2>\n\n\n\n

                Use pagina\u00e7\u00e3o<\/strong><\/strong><\/h3>\n\n\n\n

                Se um endpoint de API retornar uma grande quantidade de dados, use pagina\u00e7\u00e3o.
                O uso de pagina\u00e7\u00e3o permite a API trabalhar de forma mais eficiente com os dados na comunica\u00e7\u00e3o entre cliente e servidor, trafegando apenas o necess\u00e1rio.
                Como o resultado ser\u00e1 fragmentado no servidor, a resposta da mensagem trafegada fica bem menor, e por isso, o cliente consegue o resultado da requisi\u00e7\u00e3o muito mais r\u00e1pido, criando uma experi\u00eancia agrad\u00e1vel em termos de performance ao consumidor da API.
                Como o consumo dos dados fica sob demanda, isso ajuda muito na escalabilidade vertical e horizontal da API.
                [*] Essa pr\u00e1tica permite o uso dos recursos de infraestrutura de forma mais inteligente.<\/strong><\/p>\n\n\n\n

                \n
                \n
                \"\"
                Pagina\u00e7\u00e3o para grande quantidade de dados<\/figcaption><\/figure>\n\n\n\n
                \"\"
                T\u00e9cnicas de pagina\u00e7\u00e3o<\/figcaption><\/figure>\n<\/div>\n\n\n\n
                \n

                Existem alguns esquemas para implementar a pagina\u00e7\u00e3o, como por exemplo:<\/p>\n\n\n\n

                  \n
                • Uso de cursor <\/strong>na pagina\u00e7\u00e3o<\/li>\n\n\n\n
                • Uso de page <\/strong>e pagesize <\/strong>na pagina\u00e7\u00e3o.<\/li>\n\n\n\n
                • Uso de offset <\/strong>e limit <\/strong>como t\u00e9cnica de pagina\u00e7\u00e3o.<\/li>\n<\/ul>\n\n\n\n

                  A pagina\u00e7\u00e3o baseada em offset e limit <\/strong>\u00e9 utilizada a partir de um deslocamento de registros.
                  Voc\u00ea especifica em offset a partir de qual registro voc\u00ea quer os dados, e em limit voc\u00ea especifica o limite de registros a serem retornados.
                  Como medida de boa pr\u00e1tica, se “limit<\/strong>” e “offset<\/strong>” n\u00e3o forem especificados, o servidor deve assumir valores padr\u00e3o sensatos.<\/p>\n<\/div>\n<\/div>\n\n\n\n

                  Use versionamento<\/strong><\/strong><\/h3>\n\n\n\n

                  O controle de vers\u00e3o de uma API \u00e9 muito importante por isso tome essa decis\u00e3o j\u00e1 no in\u00edcio do seu projeto.
                  O controle de vers\u00e3o permite que uma implementa\u00e7\u00e3o forne\u00e7a compatibilidade com vers\u00f5es anteriores, de modo que, se introduzirmos altera\u00e7\u00f5es significativas de uma vers\u00e3o para outra, os consumidores da API ter\u00e3o tempo suficiente para passar para a pr\u00f3xima vers\u00e3o.<\/p>\n\n\n\n

                  \n
                  \n

                  Existem algumas t\u00e9cnicas utilizadas para versionar APIs, por exemplo:<\/p>\n\n\n\n

                    \n
                  • Customiza\u00e7\u00e3o via Header<\/li>\n\n\n\n
                  • Utiliza\u00e7\u00e3o de par\u00e2metros via Querystring<\/li>\n\n\n\n
                  • Versionamento por URI<\/strong> ou PATH<\/li>\n<\/ul>\n\n\n\n

                    De longe o versionamento por URI \u00e9 o mais utilizado e a maneira mais direta de fazer isso \u00e9 prefixar a vers\u00e3o antes do recurso no URI.
                    Para identificar erros na mudan\u00e7a de vers\u00e3o de uma API voc\u00ea pode utilizar os seguintes c\u00f3digos HTTP:<\/p>\n\n\n\n

                      \n
                    • 301 Moved permanently<\/strong> Indicando que o recurso foi movido permanentemente para outro URI<\/li>\n\n\n\n
                    • 302 not found<\/strong> Indicando que o recurso solicitado est\u00e1 temporariamente localizado em outro local<\/li>\n<\/ul>\n<\/div>\n\n\n\n
                      \n
                      \"\"
                      Versionamento<\/figcaption><\/figure>\n\n\n\n
                      \"\"
                      M\u00e9todos de versionamento<\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n

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

                      A API RESTful \u00e9 simples e eficaz quando aplicada de forma sensata.
                      Pode n\u00e3o ser a melhor escolha para todas as empresas e cen\u00e1rios, mas \u00e9 simples e boa o suficiente e \u00c9 EXATAMENTE POR ISSO QUE \u00c9 AMPLAMENTE UTILIZADA.<\/strong>

                      Existem outras op\u00e7\u00f5es populares de padr\u00e3o de API, como o GraphQL <\/strong>e gRPC <\/strong>e pretendo discuti-los e compar\u00e1-los em outros artigos.

                      Se voc\u00ea gostou desse assunto, acompanhe nossas postagens, Youtube e redes sociais para ficar bem informado sobre tecnologias de desenvolvimento e TI.<\/p>\n","protected":false},"excerpt":{"rendered":"

                      Toda API REST implementada em conformidade com as seis restri\u00e7\u00f5es do padr\u00e3o REST \u00e9 considerada uma API RESTful.<\/p>\n","protected":false},"author":1,"featured_media":743,"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\",\"comments\",\"post-navigation\"]","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","_themeisle_gutenberg_block_has_review":false,"footnotes":""},"categories":[8],"tags":[9],"class_list":["post-353","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-desenho-de-sistemas","tag-desenho-de-sistemas"],"_links":{"self":[{"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/posts\/353","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=353"}],"version-history":[{"count":1,"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/posts\/353\/revisions"}],"predecessor-version":[{"id":744,"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/posts\/353\/revisions\/744"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/media\/743"}],"wp:attachment":[{"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/media?parent=353"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/categories?post=353"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vadebyte.com\/index.php\/wp-json\/wp\/v2\/tags?post=353"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}