A transferência representacional de estado (REST) é um estilo de arquitetura de software que define um conjunto de restrições a ser usado para criar web services. Os web services que estão em conformidade com o estilo de arquitetura REST, chamados de RESTful Web Services (RWS), fornecem interoperabilidade entre sistemas de computador na Internet. Os RESTful web services permitem que os sistemas solicitantes acessem e manipulem representações textuais de recursos web usando um conjunto uniforme e predefinido de operações sem estado. Outros tipos de web services, como SOAP web services, expõem seus próprios conjuntos arbitrários de operações.
Ser um programador hoje em dia é basicamente uma versão nerd de ser um poliglota. Claro, a maioria de nós aqui na comunidade InterSystems "falamos ObjectScript". Entretando, eu acredito que essa não foi a primeira língua de muita gente. Por exemplo, eu nunca tinha ouvido falar nela antes de receber o treinamento apropriado na Innovatium.
O InterSystems IRIS a partir da versão 2022.2 inclui a capacidade de autenticar uma API REST usando JSON web tokens (JWTs). Esse recurso aprimora a segurança ao limitar quando e com que frequência as senhas são transferidas pela rede, além de definir um tempo de expiração para o acesso.
O objetivo deste artigo é servir como um tutorial de como implementar uma API REST simulada usando o InterSystems IRIS e bloquear o acesso a ela com JWTs.
Estou montando uma API REST dentro do Cache e queria saber como eu coloco um middleware para fazer algumas validações antes de chamar a função de fato, estive procurando na documentação e não consegui localizar, quais as estratégias que vocês recomendam?!
Digamos que eu esteja desenvolvendo uma aplicação web que usa o IRIS como back-end. Estou trabalhando nela com acesso não autenticado. Está chegando a hora em que eu gostaria de implantar para os usuários, mas preciso adicionar a autenticação primeiro. Em vez de usar a autenticação padrão de senha do IRIS, quero que os usuários façam login com o Login Único (single sign-on - SSO, na sigla em inglês) da minha organização ou outro provedor de identidade popular, como Google ou GitHub. Li que o OpenID Connect é um padrão de autenticação comum e compatível com o IRIS.
Recentemente eu precisei gerar uma especificação Swagger a partir de classes persistentes e seriais, então estou publicando meu código (ainda incompleto - você ainda precisa resolver detalhes específicos do aplicativo mas é um começo). Ele está disponível aqui.
O InterSystems IRIS 2019.1 já foi lançado há algum tempo e gostaria de abordar algumas melhorias para lidar com JSON que podem ter passado despercebidas.Lidar com JSON como um formato de serialização é uma parte importante da construção de aplicativos modernos, especialmente ao interagir com terminais REST.
O mesmo serviço com a possibilidade de receber várias consultas SQL diferentes e sempre entregar o resultado independente de quantas colunas distintas tenham essas diferentes consultas. Aqui demonstro como pode ser possível montar esse tipo de serviço utilizando o Service Bus da Intersystems.
Possível cenário (Desconsiderar o uso de um BI):
Vamos pensar em um painel real time onde iremos fornecer as informações de consumo de um material por região para o setor de compras e teremos as informações do nome do produto, fabricante e quantidade por exemplo.
Por padrão, o InterSystems IRIS expõe seus endpoints usando http, mas pode ser necessário executar https em seu ambiente de desenvolvimento e / ou obter acesso público à Internet para seu aplicativo. Você pode comprar ou obter um certificado e configurar um gateway, gastando muitas horas ou usando um ótimo serviço público chamado ngrok. Siga os passos:
1 - Execute seu aplicativo, usarei o template FHIR como amostra, veja:
Publicado o novo lançamento da versão 1.5 do InterSystems API Manager (IAM).
O contêiner do IAM, incluindo todos os artefatos necessários para realizar a atualização a partir de versões anteriores do IAM podem ser baixados do site de Distribuição de Software do WRC na área de Componentes.
O número de registro deste lançamento é IAM 1.5.0.9-4.
O OpenAPI-Client Gen acaba de ser lançado, este é um aplicativo para criar um cliente de produção de interoperabilidade IRIS a partir da especificação Swagger 2.0.
Em vez da ferramenta existente ^%REST que cria um aplicativo REST do lado do servidor, o OpenAPI-Client Gen cria um modelo de cliente de produção de interoperabilidade REST completo.
Nesta série de artigos de três partes, é mostrado como você pode usar o IAM para simplesmente adicionar segurança, de acordo com os padrões do OAuth 2.0, a um serviço não autenticado anteriormente implantado no IRIS.
Na primeira parte, foram fornecidos alguns conhecimentos sobre o OAuth 2.0, juntamente com algumas definições e configurações iniciais do IRIS e IAM, para facilitar a compreensão de todo o processo de proteção dos seus serviços.
Neste artigo eu gostaria de falar sobre a abordagem de especificação primeiro (spec-first) para o desenvolvimento de APIs REST.
Embora o desenvolvimento de API REST com código primeiro (code-first) tradicional seja assim:
Escrever o código
Habilitando-o com REST
Documentando-o (como uma API REST)
A especificação primeiro (spec-first) segue os mesmos passo, mas ao contrário. Começamos com uma especificação, também usando-a como documentação, geramos uma aplicação REST padrão a partir dela e, finalmente, escrevemos alguma lógica de negócios.
Isso é vantajoso porque:
Você sempre tem uma documentação relevante e útil para desenvolvedores externos ou front-end que desejam usar sua API REST
A especificação criada em OAS (Swagger) pode ser importada em uma variedade de ferramentas permitindo edição, geração de cliente, gerenciamento de API, teste de unidade e automação ou simplificação de muitas outras tarefas
Arquitetura de API aprimorada. Na abordagem de código primeiro (code-first), a API é desenvolvida método a método então um desenvolvedor pode facilmente perder o controle da arquitetura geral da API, no entanto, com a especificação primeiro (spec-first), o desenvolvedor é forçado a interagir com uma API a partir da posição de um consumidor de API, o que geralmente ajuda no design de uma arquitetura melhor da API.
Desenvolvimento mais rápido - como todo código padrão é gerado automaticamente, você não terá que escrevê-lo, tudo o que resta é desenvolver a lógica de negócios.
Loops de feedback mais rápidos - os consumidores podem obter uma visão da API imediatamente e podem oferecer sugestões com mais facilidade, simplesmente modificando as especificações
Vamos desenvolver nossa API em uma abordagem de especificação primeiro!
Estamos na era da economia multi-plataforma, e as API's são a "liga" deste cenário digital. Sendo tão importantes, elas são encaradas por desenvolvedores como um serviço ou produto a ser consumido. Assim sendo, a experiência na sua utilização é um fator crucial de sucesso.
Hoje em dia existem muitas aplicações que estão usando o Open Authorization framework (OAuth) para acessar recursos de todos os tipos de serviços de maneira segura, confiável e eficiente. O InterSystems IRIS já é compatível com a estrutura OAuth 2.0, na verdade, há um ótimo artigo na comunidade sobre OAuth 2.0 e InterSystems IRIS no seguinte link aqui.
Por atualização
Open Exchange app
.png)