{"id":6682,"date":"2025-11-17T00:51:04","date_gmt":"2025-11-17T00:51:04","guid":{"rendered":"https:\/\/www.detus.co\/?p=6682"},"modified":"2026-01-21T10:39:19","modified_gmt":"2026-01-21T10:39:19","slug":"nao-precisamos-de-firmware-otimizado-apenas-algo-funcional-vamos-testar-essa-ideia","status":"publish","type":"post","link":"https:\/\/www.detus.co\/pt\/desenvolvimento-de-firmware\/nao-precisamos-de-firmware-otimizado-apenas-algo-funcional-vamos-testar-essa-ideia\/","title":{"rendered":"N\u00e3o precisamos de firmware otimizado, apenas algo funcional. Vamos testar essa ideia."},"content":{"rendered":"<div data-elementor-type=\"wp-post\" data-elementor-id=\"6682\" class=\"elementor elementor-6682\" data-elementor-post-type=\"post\">\n\t\t\t\t<div class=\"elementor-element elementor-element-ddb5b1f e-flex e-con-boxed qodef-elementor-content-no e-con e-parent\" data-id=\"ddb5b1f\" data-element_type=\"container\" data-e-type=\"container\">\n\t\t\t\t\t<div class=\"e-con-inner\">\n\t\t\t\t<div class=\"elementor-element elementor-element-470a842 elementor-widget elementor-widget-text-editor\" data-id=\"470a842\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t\t\t\t\t\t<p>Na engenharia eletr\u00f3nica, o firmware \u00e9 frequentemente a base invis\u00edvel que determina se um produto prospera ou falha. No entanto, muitas equipas caem no mesmo racioc\u00ednio durante o desenvolvimento inicial: \u201cn\u00e3o precisamos de firmware otimizado, s\u00f3 precisamos de algo funcional\u201d.<\/p><p>\u00c0 primeira vista, esta parece uma decis\u00e3o pragm\u00e1tica. A prioridade imediata \u00e9 avan\u00e7ar rapidamente, demonstrar a funcionalidade e provar que o hardware e o software podem comunicar. Uma solu\u00e7\u00e3o r\u00e1pida parece satisfazer as partes interessadas, reduzir a press\u00e3o e manter o projeto a avan\u00e7ar.<\/p><p>No entanto, no momento em que um produto sai do laborat\u00f3rio e entra em condi\u00e7\u00f5es reais, o firmware funcional sem otimiza\u00e7\u00e3o revela rapidamente as suas limita\u00e7\u00f5es. \u00c9 nessas fases que os atalhos de design se transformam em riscos, custos e, por vezes, numa falha completa do produto.<\/p><p>Portanto, este artigo testar\u00e1 a ideia de que a funcionalidade por si s\u00f3 \u00e9 suficiente, e mostrar\u00e1 porque a otimiza\u00e7\u00e3o n\u00e3o \u00e9 apenas uma reflex\u00e3o tardia, mas uma decis\u00e3o estrat\u00e9gica no desenvolvimento de produtos.<span style=\"color: #2f3032; font-family: 'Days one'; font-size: 42px;\">\u00a0<\/span><\/p><h2><a id=\"_38d589q6osjn\"><\/a><strong>A origem da mentalidade \u201capenas funcional\u201d<\/strong><\/h2><p>A maioria das equipas de engenharia est\u00e1 sob press\u00e3o para entregar. Prazos, expectativas dos investidores e a necessidade de validar um conceito levam as equipas a codificar rapidamente. Nessas circunst\u00e2ncias, o firmware \u00e9 frequentemente escrito com um objetivo: fazer o sistema responder, independentemente da efici\u00eancia com que o faz.<\/p><p>As raz\u00f5es pelas quais esta mentalidade surge s\u00e3o claras:<\/p><ul><li>Velocidade de prototipagem: investidores e clientes querem prova de conceito o mais cedo poss\u00edvel.<\/li><li>Restri\u00e7\u00f5es de recursos: horas de engenharia limitadas e or\u00e7amentos apertados incentivam a codifica\u00e7\u00e3o m\u00ednima.<\/li><li>Focar primeiro no hardware: as equipas veem frequentemente o design do hardware como o desafio central, deixando o firmware para \u201capanhar o comboio\u201d.<\/li><li>Falsa sensa\u00e7\u00e3o de seguran\u00e7a: a suposi\u00e7\u00e3o de que o firmware pode ser sempre corrigido ou otimizado mais tarde.<\/li><\/ul><p>Como resultado, esta abordagem pode acelerar as fases iniciais de desenvolvimento. Contudo, \u00e9 igualmente importante reconhecer o que acontece quando o firmware permanece apenas funcional.<\/p><h2><a id=\"_a6mlnx8uilj3\"><\/a><strong>Um breve olhar sobre a evolu\u00e7\u00e3o do firmware<\/strong><\/h2><p>Nos prim\u00f3rdios dos sistemas embarcados, a otimiza\u00e7\u00e3o n\u00e3o era opcional. Os engenheiros que escreviam c\u00f3digo para microcontroladores de 8 bits com apenas alguns kilobytes de mem\u00f3ria n\u00e3o tinham outra op\u00e7\u00e3o sen\u00e3o extrair cada ciclo de efici\u00eancia. Uma rotina mal otimizada significava que o sistema n\u00e3o podia funcionar de todo.<\/p><p>Hoje, o panorama \u00e9 diferente. Microcontroladores mais potentes e mem\u00f3ria barata possibilitaram a ado\u00e7\u00e3o de c\u00f3digo funcional. Esta mudan\u00e7a refor\u00e7ou a ideia de que a otimiza\u00e7\u00e3o \u00e9 opcional.<\/p><p>No entanto, os produtos modernos tamb\u00e9m enfrentam novas exig\u00eancias: consumo de energia ultrabaixo, rigorosos padr\u00f5es de certifica\u00e7\u00e3o, amea\u00e7as de ciberseguran\u00e7a e diferencia\u00e7\u00e3o competitiva. Embora o hardware se tenha tornado mais capaz, a margem de erro n\u00e3o desapareceu. Na verdade, a crescente complexidade dos dispositivos significa que a otimiza\u00e7\u00e3o se tornou mais estrat\u00e9gica do que nunca.<\/p><h2><a id=\"_8n937at2xjp1\"><\/a><strong>O que acontece quando o firmware n\u00e3o \u00e9 otimizado<\/strong><\/h2><p>Firmware que prioriza a funcionalidade mas negligencia a otimiza\u00e7\u00e3o traz inevitavelmente uma s\u00e9rie de problemas.<\/p><h3><a id=\"_yylv71zf79x3\"><\/a><strong>Problemas de desempenho<\/strong><\/h3><ul><li>Aumento da lat\u00eancia em aplica\u00e7\u00f5es em tempo real.<\/li><li>Tratamento ineficiente de interrup\u00e7\u00f5es que leva a respostas lentas.<\/li><li>M\u00e1 sincroniza\u00e7\u00e3o com sensores ou dispositivos externos.<\/li><\/ul><h3><a id=\"_wh0iv4gj988e\"><\/a><strong>Stress de hardware<\/strong><\/h3><ul><li>Consumo excessivo de energia em sistemas a bateria.<\/li><li>Utiliza\u00e7\u00e3o mais elevada da CPU que for\u00e7a o hardware a trabalhar no limite.<\/li><li>Fugas de mem\u00f3ria ou aloca\u00e7\u00e3o de mem\u00f3ria ineficiente que causam instabilidade.<\/li><\/ul><h3><a id=\"_gyq15b1pp1lq\"><\/a><strong>Vulnerabilidades de seguran\u00e7a<\/strong><\/h3><ul><li>Atalhos no desenvolvimento muitas vezes deixam c\u00f3digo desprotegido.<\/li><li>A falta de tratamento de erros robusto exp\u00f5e os sistemas a falhas.<\/li><li>Estruturas fracas tornam mais f\u00e1cil para os atacantes explorarem o firmware.<\/li><\/ul><h3><a id=\"_y1iff4repwfm\"><\/a><strong>Falhas de certifica\u00e7\u00e3o e conformidade<\/strong><\/h3><ul><li>Muitas ind\u00fastrias, incluindo a autom\u00f3vel, a m\u00e9dica e a eletr\u00f3nica industrial, exigem conformidade rigorosa.<\/li><li>Firmware que \u201csimplesmente funciona\u201d raramente cumpre normas como a ISO 26262 ou a IEC 62304.<\/li><li>Atrasos nos processos de certifica\u00e7\u00e3o podem, por conseguinte, bloquear a entrada no mercado.<\/li><\/ul><p>Consequentemente, o que parecia ser uma escolha que poupava tempo no in\u00edcio pode vir a tornar-se uma longa cadeia de obst\u00e1culos mais tarde.<\/p><h2>\u00a0<\/h2><h2><a id=\"_oxgllaha95lj\"><\/a><strong>Um exemplo pr\u00e1tico: autonomia da bateria<\/strong><\/h2><p>Considere dois dispositivos sensores inteligentes, ambos alimentados pela mesma bateria de l\u00edtio de 2000 mAh.<\/p><ul><li>As primeiras execu\u00e7\u00f5es de firmware deixam o MCU num estado de maior consumo de energia por mais tempo do que o necess\u00e1rio, consumindo 25 mA em idle.<\/li><li>O segundo usa firmware otimizado com ciclos de \"deep sleep\" e \"wake-ups\" controlados por interrup\u00e7\u00f5es, consumindo apenas 5 mA em repouso.<\/li><\/ul><p>Os resultados s\u00e3o:<\/p><ul><li>A 25 mA, a bateria esgota-se em cerca de 80 horas de tempo de inatividade.<\/li><li>A 5 mA, a mesma bateria dura mais de 400 horas.<\/li><\/ul><p>Esta diferen\u00e7a traduz-se em meses ou mesmo anos de vida \u00fatil adicional do produto. Para um dispositivo de consumo, isto pode significar evitar avalia\u00e7\u00f5es negativas e devolu\u00e7\u00f5es ao abrigo da garantia. Para um sensor industrial implementado em milhares de locais, isto pode significar evitar viagens de servi\u00e7o que custam milhares de euros.<span style=\"color: #2f3032; font-family: 'Days one'; font-size: 42px;\">\u00a0<\/span><\/p><h2>\u00a0<\/h2><h2><a id=\"_i6pzmo51o4qd\"><\/a><strong>O custo do firmware \u201capenas funcional\u201d<\/strong><\/h2><p>A despesa real de um firmware que carece de otimiza\u00e7\u00e3o n\u00e3o aparece imediatamente. Em vez disso, acumula-se ao longo do tempo, surgindo frequentemente durante a escalabilidade e comercializa\u00e7\u00e3o.<\/p><table><thead><tr><th><p><strong>Fase (ligada ao roteiro do produto)<\/strong><\/p><\/th><th><p><strong>Custo oculto<\/strong><\/p><\/th><th><p><strong>Exemplo<\/strong><\/p><\/th><\/tr><tr><th><p>Fase 1-2: Prova de conceito e MVP<\/p><\/th><th><p>Entrega mais r\u00e1pida, mas com elevada d\u00edvida t\u00e9cnica<\/p><\/th><th><p>C\u00f3digo pronto a usar reutilizado sem estrutura<\/p><\/th><\/tr><tr><th><p>Fase 3\u20134: Prot\u00f3tipo funcional e EVT<\/p><\/th><th><p>A depura\u00e7\u00e3o est\u00e1 a sair do controlo<\/p><\/th><th><p>Engenheiros passam semanas a rastrear falhas intermitentes<\/p><\/th><\/tr><tr><th><p>Etapa 6: Valida\u00e7\u00e3o e certifica\u00e7\u00e3o<\/p><\/th><th><p>Altera\u00e7\u00f5es ao hardware necess\u00e1rias<\/p><\/th><th><p>Firmware ineficiente for\u00e7a chips de mem\u00f3ria maiores a passar em testes<\/p><\/th><\/tr><tr><th><p>Est\u00e1gio 8\u20139: Lan\u00e7amento e p\u00f3s-lan\u00e7amento<\/p><\/th><th><p>Os custos de manuten\u00e7\u00e3o disparam<\/p><\/th><th><p>Atualiza\u00e7\u00f5es frequentes corroem a fiabilidade e a confian\u00e7a dos clientes<\/p><\/th><\/tr><\/thead><\/table><p>Adicionalmente, outros custos ocultos incluem:<\/p><ul><li>Horas-homem: depurar c\u00f3digo n\u00e3o estruturado consome exponencialmente mais recursos do que construir firmware otimizado desde o in\u00edcio.<\/li><li>Sobre-compensa\u00e7\u00e3o de hardware: quando o firmware \u00e9 ineficiente, as empresas geralmente resolvem o problema atualizando o hardware desnecessariamente.<\/li><li>Risco de reputa\u00e7\u00e3o: firmware inst\u00e1vel em dispositivos IoT ou industriais pode levar a recalls e perda de contratos.<\/li><\/ul><p>Portanto, embora firmware \u201capenas funcional\u201d possa poupar tempo a curto prazo, geralmente gera custos financeiros e t\u00e9cnicos mais elevados mais tarde.<\/p><h2>\u00a0<\/h2><h2><a id=\"_2e4y8tn8a3gv\"><\/a><strong>Compara\u00e7\u00e3o: firmware funcional vs. firmware otimizado<\/strong><\/h2><table><thead><tr><th><p><strong>Fatorar<\/strong><\/p><\/th><th><p><strong>Firmware apenas funcional<\/strong><\/p><\/th><th><p><strong>Firmware otimizado<\/strong><\/p><\/th><\/tr><tr><th><p>Velocidade de desenvolvimento<\/p><\/th><th><p>Muito r\u00e1pido na fase de prot\u00f3tipo<\/p><\/th><th><p>Um pouco mais lento no in\u00edcio<\/p><\/th><\/tr><tr><th><p>Utiliza\u00e7\u00e3o de hardware<\/p><\/th><th><p>Frequentemente excessivo<\/p><\/th><th><p>Eficiente e equilibrado<\/p><\/th><\/tr><tr><th><p>Prepara\u00e7\u00e3o para certifica\u00e7\u00e3o<\/p><\/th><th><p>Risco elevado de rejei\u00e7\u00e3o<\/p><\/th><th><p>Maior probabilidade de aprova\u00e7\u00e3o<\/p><\/th><\/tr><tr><th><p>Autonomia da bateria<\/p><\/th><th><p>Severamente reduzido<\/p><\/th><th><p>Maximizado<\/p><\/th><\/tr><tr><th><p>Manutenibilidade<\/p><\/th><th><p>Dif\u00edcil de escalar<\/p><\/th><th><p>Estruturado e modular<\/p><\/th><\/tr><\/thead><\/table><p>Esta compara\u00e7\u00e3o lado a lado mostra porque a diferen\u00e7a entre \u201cbom o suficiente\u201d e \u201cotimizado\u201d decide muitas vezes se um produto tem sucesso comercialmente.<\/p><h2><a id=\"_kh1yjfgpakwo\"><\/a><strong>Quando \u201csimplesmente funcional\u201d funciona<\/strong><\/h2><p>Existem, claro, situa\u00e7\u00f5es em que firmware n\u00e3o otimizado \u00e9 aceit\u00e1vel.<\/p><ul><li>Prova de conceito inicial: quando o \u00fanico objetivo \u00e9 validar a viabilidade do hardware.<\/li><li>Prot\u00f3tipos internos: dispositivos usados puramente para testes que nunca chegam ao mercado.<\/li><li>Sistemas de baixo risco: aplica\u00e7\u00f5es onde o desempenho, a seguran\u00e7a e a conformidade s\u00e3o irrelevantes.<\/li><\/ul><p>Mesmo assim, em todos estes casos, a equipa deve estabelecer um limite claro. O firmware funcional \u00e9 tempor\u00e1rio e nunca deve ser tratado como pronto para produ\u00e7\u00e3o. Caso contr\u00e1rio, o que come\u00e7a como um atalho pode silenciosamente tornar-se a base do produto final.<\/p><h2><a id=\"_t36j79n38y5j\"><\/a><strong>O caminho para o desenvolvimento equilibrado de firmware<\/strong><\/h2><p>Em vez de verem o firmware funcional e otimizado como opostos, as equipas devem definir um roteiro que equilibre ambos.<\/p><h3><a id=\"_m0wyc79x1izq\"><\/a><strong>Boas pr\u00e1ticas para equil\u00edbrio<\/strong><\/h3><ul><li>Defini\u00e7\u00e3o de marco: determinar quando a funcionalidade \u00e9 suficiente para valida\u00e7\u00e3o e quando a otimiza\u00e7\u00e3o deve come\u00e7ar.<\/li><li>Desenvolvimento modular: desenhar firmware em m\u00f3dulos que podem ser otimizados de forma independente.<\/li><li>Mentalidade de escalabilidade: escreva c\u00f3digo funcional de forma a antecipar otimiza\u00e7\u00f5es futuras.<\/li><li>Testes automatizados: implemente testes cont\u00ednuos para detetar problemas de desempenho ou estabilidade precocemente.<\/li><\/ul><p>Por exemplo, uma empresa que desenvolve um sensor IoT pode come\u00e7ar com um firmware que l\u00ea dados e os envia para um gateway. Uma vez validado, a otimiza\u00e7\u00e3o dever\u00e1 focar-se ent\u00e3o na redu\u00e7\u00e3o do consumo de energia e na garantia de transfer\u00eancia de dados fi\u00e1vel \u00e0 escala.<\/p><h2><a id=\"_wtl9n516oerz\"><\/a><strong>Perspetiva mais ampla: firmware como parte do sistema<\/strong><\/h2><p>O firmware nunca est\u00e1 isolado. Firmware ineficiente pode desencadear altera\u00e7\u00f5es em toda a arquitetura de um produto.<\/p><ul><li>Poder\u00e3o ser necess\u00e1rias novas conce\u00e7\u00f5es do PCB caso a mem\u00f3ria ou o consumo de energia excedam as expectativas originais.<\/li><li>Os custos do BOM podem aumentar quando as equipas adicionam componentes maiores para compensar c\u00f3digo ineficiente.<\/li><li>O design t\u00e9rmico pode tornar-se mais complexo se o firmware for\u00e7ar os processadores a funcionar a temperaturas mais elevadas.<\/li><\/ul><p>Portanto, ignorar a otimiza\u00e7\u00e3o no firmware acarreta consequ\u00eancias que v\u00e3o muito para al\u00e9m do software. Pode remodelar o design f\u00edsico do produto e inflacionar os custos gerais.<\/p><h2><a id=\"_vg6eu2nve481\"><\/a><strong>Por que o firmware otimizado \u00e9 um ativo estrat\u00e9gico<\/strong><\/h2><p>O firmware otimizado n\u00e3o se trata apenas de efici\u00eancia t\u00e9cnica. Ele proporciona vantagens estrat\u00e9gicas que influenciam todo o ciclo de vida do produto.<\/p><h3><a id=\"_ob6ti7pmki3o\"><\/a><strong>Longevidade<\/strong><\/h3><p>Produtos com firmware est\u00e1vel e eficiente duram mais em campo e, consequentemente, reduzem os custos de suporte.<\/p><h3><a id=\"_emu91c9bzzij\"><\/a><strong>Efici\u00eancia<\/strong><\/h3><p>Um c\u00f3digo otimizado garante um baixo consumo de energia, uma melhor utiliza\u00e7\u00e3o do hardware e a redu\u00e7\u00e3o da necessidade de atualiza\u00e7\u00f5es.<\/p><h3><a id=\"_cebn0tk2au8j\"><\/a><strong>Confian\u00e7a e conformidade<\/strong><\/h3><p>Firmware fi\u00e1vel gera confian\u00e7a nos clientes e facilita a aprova\u00e7\u00e3o em certifica\u00e7\u00f5es regulamentares.<\/p><h3><a id=\"_oufcqsinc7um\"><\/a><strong>Vantagem competitiva<\/strong><\/h3><p>Em mercados competitivos, o desempenho e a fiabilidade tornam-se frequentemente os fatores decisivos para a ado\u00e7\u00e3o.<\/p><p>Como resultado, a otimiza\u00e7\u00e3o n\u00e3o \u00e9 um aperfei\u00e7oamento opcional, mas sim um investimento em resili\u00eancia, satisfa\u00e7\u00e3o do cliente e sucesso comercial.<\/p><h2><a id=\"_1cmhoiquyt7b\"><\/a><strong>Lista de verifica\u00e7\u00e3o: quando passar do modo funcional para o otimizado<\/strong><\/h2><p>Para ajudar as equipas a decidir quando mudar prioridades, apresentamos uma lista de verifica\u00e7\u00e3o pr\u00e1tica.<\/p><ul><li>O prot\u00f3tipo j\u00e1 provou a funcionalidade b\u00e1sica?<\/li><li>O dispositivo est\u00e1 a mover-se para testes piloto ou certifica\u00e7\u00e3o?<\/li><li>O firmware funcionar\u00e1 com bateria por longos per\u00edodos?<\/li><li>O sistema destina-se a ind\u00fastrias regulamentadas, como a m\u00e9dica ou a autom\u00f3vel?<\/li><li>O custo de manuten\u00e7\u00e3o superar\u00e1 o custo da otimiza\u00e7\u00e3o precoce?<\/li><\/ul><p>Se a resposta a alguma destas perguntas for sim, ent\u00e3o a otimiza\u00e7\u00e3o deve come\u00e7ar imediatamente.<\/p><p><strong>Olhando em frente: o futuro do firmware<\/strong><\/p><p>\u00c0 medida que os sistemas se tornam mais interligados e as ind\u00fastrias adotam a AIoT, a Ind\u00fastria 4.0 e dispositivos aut\u00f3nomos, a press\u00e3o sobre o firmware s\u00f3 aumentar\u00e1. Espera-se que os dispositivos processem mais dados, mantenham liga\u00e7\u00f5es seguras e operem com o m\u00ednimo de energia.<\/p><p>Nesse futuro, a ideia de firmware \u201capenas funcional\u201d n\u00e3o ter\u00e1 lugar. A otimiza\u00e7\u00e3o deixar\u00e1 de ser opcional, passando a ser o requisito de base para a competitividade.<\/p><h2><a id=\"_1pmkibfpj7m2\"><\/a><strong>Conclus\u00e3o<\/strong><\/h2><p>A frase\u00a0<em>n\u00e3o precisamos de firmware otimizado, apenas algo funcional<\/em>\u00a0reflete uma tenta\u00e7\u00e3o real na engenharia. Funciona em prot\u00f3tipos, onde a velocidade \u00e9 mais importante do que a efici\u00eancia. No entanto, uma vez que um produto caminha para a comercializa\u00e7\u00e3o, esta abordagem n\u00e3o se sustenta.<\/p><p>Em \u00faltima an\u00e1lise, firmware otimizado n\u00e3o \u00e9 um refinamento desnecess\u00e1rio. \u00c9 um investimento estrat\u00e9gico que previne custos, protege a fiabilidade e garante a conformidade. C\u00f3digo funcional pode funcionar em laborat\u00f3rio, mas firmware otimizado \u00e9 o que garante o sucesso de um produto no mundo real.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>","protected":false},"excerpt":{"rendered":"<p>In electronic engineering, firmware is often the invisible foundation that determines whether a product thrives or fails. Yet many teams fall into the same reasoning during early development: \u201cwe do not need optimized firmware, we only need something functional\u201d. At first glance, this feels like a pragmatic decision. The immediate priority is to move fast, [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":6687,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[4],"tags":[],"class_list":["post-6682","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-firmware-development"],"_links":{"self":[{"href":"https:\/\/www.detus.co\/pt\/wp-json\/wp\/v2\/posts\/6682","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.detus.co\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.detus.co\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.detus.co\/pt\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.detus.co\/pt\/wp-json\/wp\/v2\/comments?post=6682"}],"version-history":[{"count":1,"href":"https:\/\/www.detus.co\/pt\/wp-json\/wp\/v2\/posts\/6682\/revisions"}],"predecessor-version":[{"id":6719,"href":"https:\/\/www.detus.co\/pt\/wp-json\/wp\/v2\/posts\/6682\/revisions\/6719"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.detus.co\/pt\/wp-json\/wp\/v2\/media\/6687"}],"wp:attachment":[{"href":"https:\/\/www.detus.co\/pt\/wp-json\/wp\/v2\/media?parent=6682"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.detus.co\/pt\/wp-json\/wp\/v2\/categories?post=6682"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.detus.co\/pt\/wp-json\/wp\/v2\/tags?post=6682"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}