{"id":55231,"date":"2020-01-16T00:00:00","date_gmt":"2020-01-15T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/pro-multitenancy"},"modified":"2020-02-18T14:03:19","modified_gmt":"2020-02-18T11:03:19","slug":"pro-multitenancy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/pro-multitenancy","title":{"rendered":"Sobre multitenancy","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Infelizmente, este termo n\u00e3o tem um bom equivalente em russo. A \u00abWikipedia\u00bb fornece tradu\u00e7\u00e3o<\/a><\/noindex> \u00abmulti-inquilinos, aluguel m\u00faltiplo\u00bb. \u00c0s vezes, isso \u00e9 chamado de \u00abpropriedade m\u00faltipla\u00bb. Esses termos podem causar alguma confus\u00e3o, uma vez que o assunto n\u00e3o est\u00e1 essencialmente relacionado a aluguel ou propriedade. Trata-se de uma quest\u00e3o de arquitetura de software e da organiza\u00e7\u00e3o de sua opera\u00e7\u00e3o. E esta \u00faltima \u00e9 igualmente importante. <\/p>\n

Come\u00e7amos a formar nossa compreens\u00e3o sobre multitenancy ao mesmo tempo em que come\u00e7amos a projetar uma abordagem para o modelo de trabalho em nuvem (servi\u00e7o) do \u00ab1C:Enterprise\u00bb. Isso foi h\u00e1 alguns anos. Desde ent\u00e3o, nossa compreens\u00e3o vem se expandindo continuamente. Estamos constantemente descobrindo novos e novos aspectos (pr\u00f3s, contras, dificuldades, peculiaridades, etc.) sobre esse assunto. <\/p>\n

\"Sobre
\n<\/a><\/noindex>
\n\u00c0s vezes, os desenvolvedores entendem multitenancy como uma quest\u00e3o bastante simples: \u00abpara que os dados de v\u00e1rias organiza\u00e7\u00f5es sejam armazenados em um \u00fanico banco de dados, \u00e9 necess\u00e1rio adicionar uma coluna com o identificador da organiza\u00e7\u00e3o a todas as tabelas e aplicar um filtro sobre ela\u00bb. N\u00f3s tamb\u00e9m, \u00e9 claro, come\u00e7amos nossa reflex\u00e3o sobre o assunto a partir desse ponto. Mas rapidamente percebemos que esta \u00e9 apenas uma pequena parte (que tamb\u00e9m n\u00e3o \u00e9 simples). Na verdade, \u00e9 \u00abum verdadeiro pa\u00eds\u00bb. <\/p>\n

A ideia principal de multitenancy pode ser descrita da seguinte maneira. Um aplicativo comum \u00e9 uma casa unifamiliar, planejada para o uso de uma \u00fanica fam\u00edlia, que utiliza sua infraestrutura (paredes, telhado, abastecimento de \u00e1gua, aquecimento, etc.). J\u00e1 um aplicativo multitenancy \u00e9 um pr\u00e9dio de apartamentos. Nele, cada fam\u00edlia utiliza um conjunto semelhante de infraestrutura, mas essa infraestrutura \u00e9 implementada para todo o pr\u00e9dio como um todo. <\/p>\n

E a abordagem multitenancy \u2013 \u00e9 boa ou ruim? Pode-se encontrar opini\u00f5es muito diversas sobre isso. Parece que n\u00e3o existe um \u00abbom ou ruim\u00bb absoluto. \u00c9 preciso comparar os pr\u00f3s e contras no contexto de tarefas espec\u00edficas a serem resolvidas. Mas esse \u00e9 um tema \u00e0 parte... <\/p>\n

Em termos mais simples, o objetivo do multitenancy \u00e9 reduzir os custos de manuten\u00e7\u00e3o do aplicativo por meio da \u00abcompartilhamento\u00bb das despesas com infraestrutura. \u00c9 um movimento semelhante \u00e0 redu\u00e7\u00e3o do custo do aplicativo por meio da utiliza\u00e7\u00e3o de uma solu\u00e7\u00e3o padronizada (possivelmente, com configura\u00e7\u00e3o e personaliza\u00e7\u00e3o), e n\u00e3o da cria\u00e7\u00e3o sob medida. Apenas em um caso, o desenvolvimento \u00e9 compartilhado, enquanto no outro, a opera\u00e7\u00e3o. <\/p>\n

De fato, repetimos, aqui n\u00e3o h\u00e1 uma liga\u00e7\u00e3o direta com o modo de venda. A arquitetura de multitenancy pode ser aplicada tamb\u00e9m em infraestruturas de TI corporativas ou governamentais para automatizar um grande n\u00famero de filiais ou empresas de um grupo. <\/p>\n

Pode-se dizer que multitenancy n\u00e3o \u00e9 apenas uma quest\u00e3o de organiza\u00e7\u00e3o do armazenamento de dados. \u00c9 um modelo de opera\u00e7\u00e3o de aplicativo como um todo (incluindo uma parte substancial dos aspectos de sua arquitetura, seu modelo de implanta\u00e7\u00e3o e a organiza\u00e7\u00e3o da manuten\u00e7\u00e3o). <\/p>\n

O aspecto mais desafiador e interessante do modelo de multitenancy, ao nosso ver, \u00e9 que a ess\u00eancia do aplicativo se \"dobra\". Uma parte da funcionalidade lida com \u00e1reas de dados espec\u00edficas (apartamentos) e \"n\u00e3o se interessa\" pelo que acontece com os residentes em outros apartamentos. Enquanto a outra parte v\u00ea o pr\u00e9dio como um todo e opera simultaneamente para todos os residentes. No entanto, esta \u00faltima n\u00e3o consegue abstrair o fato de que ainda s\u00e3o apartamentos separados e \u00e9 necess\u00e1rio garantir o n\u00edvel adequado de granularidade e seguran\u00e7a. <\/p>\n

No \"1C:Enterprise\", o modelo de multitenancy \u00e9 implementado em n\u00edvel de v\u00e1rias tecnologias. Esses s\u00e3o os mecanismos da plataforma \"1C:Enterprise\", mecanismos de1C:Tecnologia de publica\u00e7\u00e3o de solu\u00e7\u00f5es 1cFresh<\/a><\/noindex>\u201d e \u201c1C:Tecnologia de desenvolvimento de solu\u00e7\u00f5es 1cFresh<\/a><\/noindex>mecanismos BSP<\/a><\/noindex> (bibliotecas de subsistemas padr\u00e3o). <\/p>\n

Cada um desses itens contribui para a constru\u00e7\u00e3o da infraestrutura geral de um pr\u00e9dio de apartamentos. Por que isso \u00e9 implementado em v\u00e1rias tecnologias, e n\u00e3o em uma \u00fanica, como na plataforma? Antes de tudo, porque parte dos mecanismos, em nossa opini\u00e3o, merece ser modificada de acordo com a variante espec\u00edfica de implanta\u00e7\u00e3o. Mas, de modo geral, essa n\u00e3o \u00e9 uma quest\u00e3o simples, e constantemente nos deparamos com a escolha de em qual n\u00edvel \u00e9 melhor implementar determinado aspecto do multitenancy. <\/p>\n

\u00c9 \u00f3bvio que a parte b\u00e1sica dos mecanismos precisava ser implementada na plataforma. Por exemplo, a separa\u00e7\u00e3o de dados em si. Isso \u00e9 normalmente o ponto de partida da discuss\u00e3o sobre multitenancy. Mas, ao final, o modelo de multitenancy passou por uma parte significativa dos mecanismos da plataforma e exigiu ajustes, e em alguns casos, at\u00e9 uma reinterpreta\u00e7\u00e3o. <\/p>\n

No n\u00edvel da plataforma, implementamos os mecanismos b\u00e1sicos. Eles permitem a cria\u00e7\u00e3o de aplicativos que operam no modelo multitenancy. Mas para que os aplicativos \"vivam e funcionem\" nesse modelo, \u00e9 necess\u00e1rio ter um sistema de gest\u00e3o de seu \"ciclo de vida\". Isso \u00e9 gerido pelas tecnologias 1cFresh e por uma camada unificada de l\u00f3gica de neg\u00f3cios no n\u00edvel do BSP. Assim como em um pr\u00e9dio de apartamentos, a infraestrutura fornece aos moradores tudo o que \u00e9 necess\u00e1rio, as tecnologias 1cFresh tamb\u00e9m fornecem tudo o que \u00e9 necess\u00e1rio para os aplicativos que operam no modelo de multitenancy. Para que os aplicativos possam interagir com essa infraestrutura (sem necessidade de modifica\u00e7\u00f5es significativas), eles incluem os correspondentes \"conectores\" na forma de subsistemas do BSP. <\/p>\n

Do ponto de vista dos mecanismos da plataforma, \u00e9 f\u00e1cil notar que, \u00e0 medida que adquirimos experi\u00eancia e avan\u00e7amos com a op\u00e7\u00e3o de uso em nuvem do \"1C:Enterprise\", ampliamos os mecanismos envolvidos nesta arquitetura. Um exemplo disso \u00e9 que, no modelo de multitenancy, a disposi\u00e7\u00e3o dos pap\u00e9is dos participantes na manuten\u00e7\u00e3o dos aplicativos muda significativamente. O papel (n\u00edvel de responsabilidade) daqueles que s\u00e3o respons\u00e1veis pela explora\u00e7\u00e3o dos aplicativos se torna muito mais importante. Eles agora precisam ter ferramentas de controle mais robustas. Isso porque os usu\u00e1rios dos aplicativos (moradores) confiam, acima de tudo, no provedor com o qual est\u00e3o trabalhando. Para isso, implementamos na vers\u00e3o 8.3 um novo mecanismo de perfis de seguran\u00e7a<\/a><\/noindex>. Este mecanismo permite que os administradores do provedor restrinjam a liberdade dos desenvolvedores de aplicativos ao n\u00edvel de seguran\u00e7a necess\u00e1rio \u2013 essencialmente, isolar o funcionamento do aplicativo para cada morador dentro de certos limites de uma \"caixa de areia\" (sandbox). <\/p>\n

A arquitetura para gerenciar aplicativos que operam em modo multitenancy (como \u00e9 implementado nas tecnologias 1cFresh e BSP) tamb\u00e9m desperta um grande interesse. Aqui, em compara\u00e7\u00e3o com o modelo tradicional de implanta\u00e7\u00e3o, os requisitos para a automa\u00e7\u00e3o dos processos de gerenciamento aumentam significativamente. Existem dezenas desses processos: cria\u00e7\u00e3o de novas \u00e1reas de dados (\"apartamentos\"), atualiza\u00e7\u00e3o de aplicativos, atualiza\u00e7\u00e3o de informa\u00e7\u00f5es regulat\u00f3rias, backup etc. E, claro, os requisitos para n\u00edveis de confiabilidade e disponibilidade tamb\u00e9m crescem. Por exemplo, para garantir uma intera\u00e7\u00e3o confi\u00e1vel entre os aplicativos e os componentes do sistema de gerenciamento, implementamos uma tecnologia de sistema de chamadas ass\u00edncronas com entrega garantida. <\/p>\n

Um ponto muito sutil \u00e9 a forma de compartilhar dados e processos. \u00c0 primeira vista, isso pode parecer simples (para alguns pode parecer). O maior desafio \u00e9 encontrar o equil\u00edbrio entre a centraliza\u00e7\u00e3o de dados e processos e a descentraliza\u00e7\u00e3o. De um lado, a centraliza\u00e7\u00e3o permite reduzir despesas (espa\u00e7o em disco, recursos do processador, esfor\u00e7os dos administradores...). Por outro lado, limita a liberdade dos \"moradores\". Este \u00e9 exatamente um dos aspectos da \"duplicidade\" do aplicativo, onde o desenvolvedor precisa pensar simultaneamente sobre o aplicativo em um sentido restrito (servindo um \"apartamento\") e em um sentido amplo (servindo a todos os \"moradores\"). <\/p>\n

Um exemplo dessa \"dilema\" pode ser encontrado nas informa\u00e7\u00f5es regulat\u00f3rias. \u00c9 claro que \u00e9 tentador torn\u00e1-las comuns a todos os \"moradores\" do pr\u00e9dio. Isso permite armazen\u00e1-las em uma \u00fanica c\u00f3pia e atualiz\u00e1-las simultaneamente para todos. Mas h\u00e1 casos em que um morador precisa de altera\u00e7\u00f5es espec\u00edficas. Estranhamente, isso ocorre na pr\u00e1tica, mesmo para informa\u00e7\u00f5es que s\u00e3o especificadas por reguladores (\u00f3rg\u00e3os governamentais). Surge uma pergunta complexa: compartilhar ou n\u00e3o compartilhar? \u00c9 tentador, \u00e9 claro, criar informa\u00e7\u00f5es comuns para todos e espec\u00edficas para aqueles que desejam. E isso j\u00e1 leva a uma implementa\u00e7\u00e3o bastante complicada. Mas estamos trabalhando nessa quest\u00e3o... <\/p>\n

Um exemplo adicional \u00e9 o projeto de implementa\u00e7\u00e3o de processos regulares (executados de acordo com um cronograma, iniciados pelo sistema de gerenciamento, etc.). Por um lado, eles podem ser implementados para cada \u00e1rea de dados separadamente. Isso \u00e9 mais simples e conveniente. Mas, por outro lado, essa granularidade fina cria uma grande carga sobre o sistema. Para reduzir a carga, \u00e9 necess\u00e1rio implementar processos centralizados. No entanto, eles exigem um trabalho mais cuidadoso. <\/p>\n

Certamente, surge uma quest\u00e3o bastante importante. Como os desenvolvedores de aplicativos podem garantir a opera\u00e7\u00e3o em um modo de multitenancy? O que eles precisam fazer para isso? Claro, buscamos que o peso das quest\u00f5es tecnol\u00f3gicas e infraestruturais recaia o m\u00e1ximo poss\u00edvel sobre a tecnologia fornecida, para que o desenvolvedor do aplicativo se concentre apenas nas tarefas da l\u00f3gica de neg\u00f3cios. Mas, assim como com outras quest\u00f5es arquitet\u00f4nicas importantes, os desenvolvedores de aplicativos precisam ter uma no\u00e7\u00e3o sobre como funciona o modelo de multitenancy, e alguns esfor\u00e7os ser\u00e3o necess\u00e1rios no desenvolvimento de aplicativos. Por qu\u00ea? Porque h\u00e1 aspectos que a tecnologia n\u00e3o pode garantir automaticamente sem considerar a sem\u00e2ntica dos dados. Por exemplo, a defini\u00e7\u00e3o das fronteiras de compartilhamento das informa\u00e7\u00f5es. Mas nos esfor\u00e7amos para que essas complexidades sejam m\u00ednimas. J\u00e1 existem exemplos da implementa\u00e7\u00e3o de tais aplicativos. <\/p>\n

Um ponto importante no contexto da implementa\u00e7\u00e3o de multitenancy no \u00ab1\u0421:\u041f\u0440\u0435\u0434\u043f\u0440\u0438\u044f\u0442\u0438\u0435\u00bb \u00e9 que estamos criando um modelo h\u00edbrido, no qual um aplicativo pode funcionar tanto em modo de multitenancy quanto em modo normal. Essa \u00e9 uma tarefa bastante complexa e um tema para discuss\u00e3o separada.
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u0443 \u044d\u0442\u043e\u0433\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430 \u043d\u0435\u0442 \u0445\u043e\u0440\u043e\u0448\u0435\u0433\u043e \u0440\u0443\u0441\u0441\u043a\u043e\u044f\u0437\u044b\u0447\u043d\u043e\u0433\u043e \u0430\u043d\u0430\u043b\u043e\u0433\u0430. \u00ab\u0412\u0438\u043a\u0438\u043f\u0435\u0434\u0438\u044f\u00bb \u0434\u0430\u0435\u0442 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u00ab\u043c\u0443\u043b\u044c\u0442\u0438\u0430\u0440\u0435\u043d\u0434\u043d\u043e\u0441\u0442\u044c, \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u0430\u0440\u0435\u043d\u0434\u0430\u00bb. \u0418\u043d\u043e\u0433\u0434\u0430 \u044d\u0442\u043e \u043d\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u00ab\u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u043c \u0432\u043b\u0430\u0434\u0435\u043d\u0438\u0435\u043c\u00bb. \u042d\u0442\u0438 \u0442\u0435\u0440\u043c\u0438\u043d\u044b \u043c\u043e\u0433\u0443\u0442 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0443\u0442\u0430\u0442\u044c, \u0442\u0430\u043a \u043a\u0430\u043a \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u043d\u0435 \u0441\u0432\u044f\u0437\u0430\u043d \u043f\u043e \u0441\u0443\u0442\u0438 \u043d\u0438 \u0441 \u0430\u0440\u0435\u043d\u0434\u043e\u0439, \u043d\u0438 \u0441 \u0432\u043b\u0430\u0434\u0435\u043d\u0438\u0435\u043c. \u042d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0438\u043c\u0435\u043d\u043d\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u0438 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0435\u0433\u043e \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438. \u041f\u0440\u0438\u0447\u0435\u043c \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0435 \u043d\u0435 \u043c\u0435\u043d\u0435\u0435 \u0432\u0430\u0436\u043d\u043e. \u041c\u044b \u043d\u0430\u0447\u0430\u043b\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":55232,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55231","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Sobre multitenancy | ProHoster","description":"Infelizmente, este termo n\u00e3o possui um bom equivalente em russo.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/pro-multitenancy","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u043e multitenancy | ProHoster","og:description":"\u041a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u0443 \u044d\u0442\u043e\u0433\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430 \u043d\u0435\u0442 \u0445\u043e\u0440\u043e\u0448\u0435\u0433\u043e \u0440\u0443\u0441\u0441\u043a\u043e\u044f\u0437\u044b\u0447\u043d\u043e\u0433\u043e \u0430\u043d\u0430\u043b\u043e\u0433\u0430.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/pro-multitenancy","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-15T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:19+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55231","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:47:39","updated":"2022-09-29 20:30:21","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/55231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=55231"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/55231\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/55232"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=55231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=55231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=55231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}