RaptorWS – Versão 1.20

Nova versão 1.20 – Mudança na estrutura Server

Na versão anterior do Raptor,  não era possível logar o contexto da requisição dentro do ServerMethod e nem exibir nenhum Log no form Principal, uma vez que a implementação de cada Server Method estava desconectada ou não tinha acesso aos dados da requisição por exemplo  : qual IP de onde partiu a requisição entre outros dados, não era possível logar essa informação de dentro do ServerMethod, apenas antes de chamá-lo.

Então uma mudança estrutural na construção da parte Server se fez necessária. Foi criada uma Unit HandleContext contendo a classe TServerContext herdada de  de TIdServerContext, onde nela coloquei o o dispatch de métodos REST conforme o tipo e isolei em classe separada os ServerMethods, dessa forma o Core do WebService fica separado  dos ServerMethods de seu negócio.

Essa mudança estrutural permite também que agora você possa ter várias Units ServerMethods separadas com uma responsabilidade única, por exemplo, numa aplicação de Gerenciamento de Escola, poderíamos ter uma unit com ServerMethods para Alunos, outra unit para Professores, outra para Material didático e assim por diante.

Classe TServerContext na Unit HandleContext :

Para essa classe foi atribuída a tarefa de obter os argumentos da requisição e chamar cada operação Rest.

Uma vantagem dessa classe é que estando num nível intermediário e antes da chamada do servermethod, que possa realizar tarefas comuns a todos os ServerMethods, poupando assim  cada ServerMethod de um trabalho repetitivo que seja comum a todos.

Outra vantagem dessa classe é que ela sendo herdada do Contexto da Requisição (TIdServerContext) teríamos todos os dados como IP de onde partiu a conexão, o User Agent, e todos os dados relativos  ao contexto, podendo ser usado para log.

CORS-HEADERS

Outra melhoria foi a adição de CORS-Headers, colaboração de José Benedito, que faz com que o servidor retorne respostas à requisições AJAX CrossDomain.

Logando dados do negócio, no ServerMethod

Na tela principal do Server foi adicionado um Log da Aplicação, onde cada ServerMethod loga a operação efetuada, como dados do IP da requisição, Nome do ServerMethod chamado e parâmetros passados ao ServerMethod. Veja o terceiro Memo é o que corresponde ao log da Aplicação (ou do negócio).  Os 2 primeiros referem-se ao servidor.

A Linha de código que faz a geração de Log é a  “Context.LogBusiness (… ” que pode ser vista em todos os serverMethods :

Migração da versão 1.11 para 1.20

Muitas alterações foram feitas nesta versão 1.20, de modo que aqueles que usavam a versão 1.1 teriam muito trabalho para adequar a esta nova estrutura, aqueles que quiserem usar a versão 1.20 tendo já implementado o seus ServerMethods na versão  1.1, baixem a versão 1.20 e tragam o código de cada ServerMethods da versão 1.1 e encaixem no local adequado da versão 1.20.

Download da versão 1.20

Estudo de Caso – Realizar tarefas comuns a todos os Server methods

Agora vou Exemplificar como Obter o Código do usuário antes da chamada de cada ServerMethod para que possa ser usado por todos os ServerMethods quando necessário, usando a Classe TServerContext.

Supondo que em todos os nossos ServerMethods padronizássemos que o código do usuário fosse passado sempre no 1o. Parâmetro, então poderíamos colocar no CallGETServerMethod antes da chamada de cada ServerMethod, a obtenção do Usuário, aí crio uma classe TUsuario onde preencho o Código do Usuário e passo esse objeto como parâmetro no ServerMethod, veja como ficaria :

Ou se preferir coloque essa implementação comum antes disso, na TServerContext.HandleRequest que é a que chama CallGETServerMethod

ServerMethods com Responsabilidade única

Supondo que num sistema de Gerenciamento de escolas tenhamos ServerMethods agrupados por responsabilidade, um para Alunos e outros para  Professores, colocar todas as responsabilidades numa única classe fica um poço sem fundo, ferindo o princípio SOLID de responsabilidade única que deve ter uma classe, e sacrificando a manutenção futura. Dessa forma você poderia organizar seus server methods em Units Separadas, cada Unit com uma nome de classe distinta  :

foram criadas 2 Units SMAlunos.pas (SM = ServerMethod) e SMProfessores, cada uma com um ServerMethod de nome Consulta. Para facilitar ainda mais coloquei na chamada do navegador o prefixo do nome do objeto, dessa forma o método SMAlunos.Consulta da classe TSMAlunos deverá ser chamado no navegador assim :

http://localhost:8080/SMAlunos.Consulta/fulano

e na CallGetServerMethod instanciaríamos cada classe e chamaremos seu método específico :

Uses :

Dessa forma podemos organizar os ServerMethods em Units separadas por responsabilidade.

Não é Show ? Espero que gostem e comentem.

Valeu.