fornecedores -> provedores; fornecendo page; new separation in Providing

Author: guim4dev

src/components/menu/templates/api.tsx

@@ -5,11 +5,13 @@ export default () => {
   return <docs-nav items={items} />
 };
 
+const requests = Object.values(menuData.apihub).flat()
+
 const items = {
   'API Hub': {
     'Introdução': '/docs/api/apihub',
     'Consumindo dados de uma Action': '/docs/api/apihub/consumindo',
-    'Fornecendo dados para uma Action': '/docs/api/apihub/fornecendo'
+    'Provendo dados para uma Action': '/docs/api/apihub/provendo'
   },
-  ...(menuData.apihub)
+  'Provendo Dados': requests
 }

src/components/menu/templates/concepts.tsx

@@ -13,7 +13,7 @@ const items = {
   },
 
   // 'Pensado para EdTechs': {
-  //   // 'Fornecedores': '/docs/concepts/fornecedores',
+  //   // 'Provedores': '/docs/concepts/Provedores',
   // },
 
   // 'Funcionalidades': {

src/pages/api/apihub.md

@@ -6,12 +6,12 @@ tableOfContents: false
 
 # Layers API Hub
 
-O Layers API Hub é uma funcionalidade do ecossistema Layers que permite Apps consumirem e fornecerem informações de outros Apps na Layers. Isto é feito através de actions: um protocolo que especifica o formato de comunicação entre os consumidores e fornecedores de informação.
+O Layers API Hub é uma funcionalidade do ecossistema Layers que permite Apps consumirem e fornecerem informações de outros Apps na Layers. Isto é feito através de actions: um protocolo que especifica o formato de comunicação entre os consumidores e Provedores de informação.
 
-Para cada uma dessas actions, está disponível ao menos um App desenvolvido pela Layers que disponibiliza essas informações. Assim, Apps fornecedores podem se responsabilizar apenas em fornecer as informações requisitadas via actions e outros Apps consumidores se responsabilizam por expor essas informações da melhor maneira para os usuários da Layers.
+Para cada uma dessas actions, está disponível ao menos um App desenvolvido pela Layers que disponibiliza essas informações. Assim, Apps Provedores podem se responsabilizar apenas em fornecer as informações requisitadas via actions e outros Apps consumidores se responsabilizam por expor essas informações da melhor maneira para os usuários da Layers.
 
 Para exemplificar, observe:
-<docs-zoomable-image href="/docs/assets/images/flow-erp.png" caption="O app mais a esquerda é o “Notas Acadêmicas” e irá representar apps que necessitam de requisitar dados (App consumidor). Já o app mais a direita é o “ERP Modelo” e irá representar os apps que podem prover dados para outros apps (App fornecedor)."></docs-zoomable-image>
+<docs-zoomable-image href="/docs/assets/images/flow-erp.png" caption="O app mais a esquerda é o “Notas Acadêmicas” e irá representar apps que necessitam de requisitar dados (App consumidor). Já o app mais a direita é o “ERP Modelo” e irá representar os apps que podem prover dados para outros apps (App Provedor)."></docs-zoomable-image>
 ## Como funciona ?
 
 + <strong> 1 - App requisita informações </strong>
@@ -20,12 +20,12 @@ O App Consumidor irá fazer uma requisição HTTP (POST) para a Layers, requisit
 
 + <strong> 2 - Layers repassa a requisição </strong>
 
-A Layers irá requisitar os dados do App Fornecedor. Este último deve receber os dados como especificados na nossa documentação. Além de fazer a requisição para o App Fornecedor, a Layers irá enriquecer os dados enviados adicionando contexto (context) a eles.
+A Layers irá requisitar os dados do App Provedor. Este último deve receber os dados como especificados na nossa documentação. Além de fazer a requisição para o App Provedor, a Layers irá enriquecer os dados enviados adicionando contexto (context) a eles.
 
 + <strong> 3 - App responde a requisição </strong>
 
-Após receber os dados, o App Fornecedor irá requisitar os dados armazenados pelo ERP (nesse caso), realizando outra requisição HTTP (POST), e retornar os dados para Layers. Novamente, seu formato de response deve seguir o que está especificado na documentação da action específica.
+Após receber os dados, o App Provedor irá requisitar os dados armazenados pelo ERP (nesse caso), realizando outra requisição HTTP (POST), e retornar os dados para Layers. Novamente, seu formato de response deve seguir o que está especificado na documentação da action específica.
 
 + <strong> 4 - Layers repassa a resposta </strong>
 
-Ao final, a Layers recebe os dados do App Fornecedor e valida-os para verificar se estão de acordo com o que era esperado como resposta da action. Caso estejam corretos, eles são repassados para o App Consumidor, assim podendo utilizá-los.
+Ao final, a Layers recebe os dados do App Provedor e valida-os para verificar se estão de acordo com o que era esperado como resposta da action. Caso estejam corretos, eles são repassados para o App Consumidor, assim podendo utilizá-los.

src/pages/api/apihub/consumindo.md

@@ -4,17 +4,17 @@ title: Consumindo uma Action
 tableOfContents: false
 previousText: 'Introdução'
 previousUrl: '/docs/api/apihub'
-nextText: 'Fornecendo Informações'
-nextUrl: '/docs/api/apihub/fornecendo'
+nextText: 'Provendo Informações'
+nextUrl: '/docs/api/apihub/provendo'
 ---
 
 # Consumindo uma Action
 
-Dada uma certa Action, antes de consumí-la, é preciso que seu App Consumidor descubra quais são os Apps Provedores disponíveis para essa Action. Após isso, é preciso que seu app requisite para cada um dos fornecedores as informações da action específica.
+Dada uma certa Action, antes de consumí-la, é preciso que seu App Consumidor descubra quais são os Apps Provedores disponíveis para essa Action. Após isso, é preciso que seu app requisite para cada um dos Provedores as informações da action específica.
 
 Para descobrir os Apps Provedores da Action, basta rodar a seguinte requisição:
 
-## Descobrindo os Apps Fornecedores
+## Descobrindo os Apps Provedores
 
 ### Request
 
@@ -50,19 +50,19 @@ community-id: {{id_da_comunidade}}
 ]
 ```
 
-A partir dessa resposta, precisamos, para cada App Fornecedor, requisitar seus dados referentes a action específica.
+A partir dessa resposta, precisamos, para cada App Provedor, requisitar seus dados referentes a action específica.
 
-## Requisitando Informações para um App Fornecedor específico
+## Requisitando Informações para um App Provedor específico
 
 ### Request
 
 ```http
-GET https://api.layers.digital/v1/services/call/{{action}}/{{id_app_fornecedor}}?version={{versao_da_action_desejada}}
+GET https://api.layers.digital/v1/services/call/{{action}}/{{id_app_Provedor}}?version={{versao_da_action_desejada}}
 ```
 
 ```headers
 Authorization: Bearer {{token_do_seu_app}}
 community-id: {{id_da_comunidade}}
 ```
 
-O corpo da mensagem varia de acordo com a action, assim como o payload de resposta. Você pode checar com detalhes nas seções logo abaixo! :) 
+O corpo da requisição varia de acordo com a action, assim como o payload de resposta. Você pode checar com detalhes nas seções logo abaixo! :) 

src/pages/api/apihub/fornecendo.md

@@ -0,0 +1,32 @@
+---
+template: default
+title: Provendos dados para uma Action
+tableOfContents: false
+previousText: 'Consumindo Informações'
+previousUrl: '/docs/api/apihub/consumindo'
+---
+
+# Provendo dados para uma Action
+
+Para um App Consumidor poder consumir dados de uma action é necessário que haja um app responsável por prover dados para essa Action. Um app com essa responsabilidade é chamado de App Provedor. Um exemplo comum desse tipo são ERPs que fornecem diversos dados como notas acadêmicas, registros médicos e etc, que podem ser utilizados por outros apps.
+
+## Respondendo por uma Action
+
+### Request
+
+Para um App Provedor ser responsável por determinada action, é necessário que sejam implementadas rotas do tipo
+
+```http
+POST https://api.layers.digital/v1/services/validate/{{action}}/{{provider_id}}
+```
+
+```headers
+Authorization: Bearer {{token_do_seu_app}}
+community-id: {{id_da_comunidade}}
+```
+
+Ou seja, para cada Action que um app é responsável por fornecer dados, é necessário que haja uma rota que responda por ela conforme especificado anteriormente.
+
+### Response
+
+A payload da resposta da requisição varia de acordo com a Action. 

src/pages/concepts/ecossistema-layers/comunidades.md

@@ -10,8 +10,8 @@ previousUrl: '/docs/concepts/ecossistema-layers'
 
 # Comunidades na Layers
 
-Comunidades são a maior unidade de organização na Layers. Cada instituição de ensino, desenvolvedor de app ou fornecedor é representada por uma comunidade na Layers que contém seus dados e na qual são instalados os apps que adicionarão funcionalidades escolhidas pelos administradores da comunidade.
+Comunidades são a maior unidade de organização na Layers. Cada instituição de ensino, desenvolvedor de app ou Provedor é representada por uma comunidade na Layers que contém seus dados e na qual são instalados os apps que adicionarão funcionalidades escolhidas pelos administradores da comunidade.
 
-Além da personalização por meio dos apps, é possível escolher também o ícone, nome e modelo de comunidade que melhor se aplica ao cenário no qual ela vai ser utilizada (escolar, desenvolvedor de apps, fornecedor, torneio, etc). 
+Além da personalização por meio dos apps, é possível escolher também o ícone, nome e modelo de comunidade que melhor se aplica ao cenário no qual ela vai ser utilizada (escolar, desenvolvedor de apps, Provedor, torneio, etc). 
 
 Para instituições com várias unidades é possível ainda definir a hierarquia de suas comunidades, definindo a comunidade da mantenedora ou sede como pai das comunidades das demais unidades. Desse modo, usuários da comunidade pai podem acessar as comunidades filhas e enviar publicações para elas.

src/pages/index.md

@@ -22,7 +22,7 @@ Para desenvolvedores desses serviços, integrar sua solução à Layers signific
     <p>Funcionalidades para Sistemas de Gestão</p>
   </docs-card>
 
-  <!-- <docs-card header="fornecedores" href="/docs/concepts/fornecedores" icon="/docs/assets/icons/Fornecedores.svg">
-    <p>Funcionalidades para fornecedores</p>
+  <!-- <docs-card header="Provedores" href="/docs/concepts/Provedores" icon="/docs/assets/icons/Provedores.svg">
+    <p>Funcionalidades para Provedores</p>
   </docs-card> -->
 </docs-cards>

tsconfig.json

@@ -6,11 +6,11 @@
     "experimentalDecorators": true,
     "lib": [
       "dom",
-      "es2017"
+      "es2019"
     ],
     "moduleResolution": "node",
     "module": "esnext",
-    "target": "es2017",
+    "target": "es2019",
     "noUnusedLocals": true,
     "noUnusedParameters": true,
     "resolveJsonModule": true,
@@ -28,4 +28,3 @@
     "node_modules"
   ]
 }
-