Closed ptalmeida closed 4 years ago
@ptalmeida boa sugestão. Poderiamos aproveitar a oportunidade e mudar para algo mais escalável. Exemplo:
API | Descrição | Tipo | Autenticação |
---|---|---|---|
FenixEdu IST | API para a plataforma FenixEdu do IST | REST | Não |
Feriados Portugueses | Lista de feriados nacionais, regionais e municipais. Suporta o cálculo dos feriados para os anos entre 1582 e 2299 | SOAP | Não |
O que te parece?
Parece-me excelente!
Iterando um pouco na ideia:
API | Descrição | Tipo | Autenticação |
---|---|---|---|
FenixEdu IST | API para a plataforma FenixEdu do IST | ✔️ | |
Feriados Portugueses | Lista de feriados nacionais, regionais e municipais. Suporta o cálculo dos feriados para os anos entre 1582 e 2299 | ❌ | |
Lorem Ipsum | texto | ✔️ | |
Lorem Ipsum2 | mais texto | ✔️ |
Penso que faltaria diferenciar também entre APIs e datasets públicos, talvez distribuídos em tabelas diferentes mas mantendo na mesma categoria para evitar repetição na tabela de conteúdos:
API | Descrição | Tipo | Autenticação |
---|---|---|---|
Lorem Ipsum | texto | ✔️ | |
Lorem Ipsum2 | mais texto | ✔️ |
Datasets | Descrição |
---|---|
Lorem Ipsum | texto |
Lorem Ipsum2 | mais texto |
Que tal?
Acrescento que penso que seria melhor organizar os dados por regiões NUTS II (ver abaixo), reduzindo a complexidade da tabela de conteúdos e sendo, na minha opinião, mais prático.
Assim, por exemplo, um API exposto pela FCT UNL ficaiar na categoria AML e não na de Setúbal.
Gosto das duas sugestões @ptalmeida. Adicionei-te como colaborador ao repositório para podermos trabalhar nisto de maneira mais eficiente.
Tendo em conta a nova organização por regiões a minha sugestão seria:
E a migração seria:
Obrigado! Então tomei a liberdade de criar um branch para irmos fazendo as alterações!
Em especial para diferenciar entre APIs SOAP, REST, GRAPHQL; por exemplo: