Frameworksp

Atalhos

Páginas filhas
  • Entendendo as novidades do REST

Versões comparadas

Versão antiga 3

changes.mady.by.user Jandir Deodato De Souza Silva

Gravado em

comparado com

Nova versão 4

changes.mady.by.user Jandir Deodato De Souza Silva

Gravado em

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Comentário: Alteração do default do novo serviço REST. O REST 2.0 somente será ligado por default a partir da lib label 20201123.

...

  • Página de 404 Not Found em HTML ao invés do retorno em Json;
  • Barras extras no endereço das requisições não são mais desconsideradas e provocam o retorno de status 404;
  • Versão 2 do SSL (Chave SSL2) descontinuada.
  • Alguns cabeçalhos informativos como FWRESTBUILD que não é mais enviado.
  • O mecanismo que mantinha a camada de accept em execução não fica mais em loop em uma thread ADVPL. Agora ela é executada a cada ciclo de refreshrate do [ONSTART] do AppServer e termina a execução após se certificar que o serviço de accept está respondendo. Essa mudança causa a escrita de mensagens extras no console, indicando que o job foi executado pelo refreshrate. Ela não está relacionada e nem exige nenhuma mudança de configuração no arquivo ini, ela ocorreu apenas por conta da mudança de arquitetura que o modelo sofreu.

  • O REST 2.0 agora sempre devolve o header Content-Type com o valor do encode utf-8. Caso seja recebido na requisição ao servidor do REST 2.0 o header Accept , com o conteúdo charset=cp1522 este será o retorno do Content-type da requisição. Exemplo:



RequisiçãoResposta do REST ADVPLResposta do RestServer 2.0Encode retornado na resposta (REST ADVPL e REST 2.0)
 Accept: charset=utf8 Content-Type: charset=utf8 Content-Type: charset=utf8A própria lib realiza o encode para utf-8
 Accept: charset=cp1252 Content-Type: charset=1252 Content-Type: charset=1252A própria lib realiza o encode para 1252 (padrão do Prothues)
VazioVazio Content-Type: charset=utf8Não é realizado encode na camada de lib.
 Accept: charset=QualquerOutroValorContent-Type: charset=QualquerOutroValorContent-Type: charset=QualquerOutroValorNão é realizado encode na camada de lib.



Com a substituição das camadas de accept e de controle já foi possível notar uma performance de resposta de requisição até 3x mais rápida com relação ao modelo ADVPL. Porém é importante ressaltar que o tempo de resposta depende muito do tipo de processamento que cada API realiza e que o ganho automático de performance se refere apenas ao tempo de pré-processamento da requisição. Com a substituição gradativa das API’s para o TLPP poderemos ter as respostas ainda mais performáticas, dependendo apenas da boa utilização da linguagem e da arquitetura adotada em cada API.

...

O REST 2.0, que será disponibilizado a partir da Lib 20201009 irá utilizar a mesma configuração de ini do [HTTPV11] e irá substituir a versão antiga de forma automática a partir da lib label 20201123. Na versão 20201009 (a ser liberada em Outubro de 2020) será necessário ligar este recurso através da chave chave ADVPL=1 na seção [HTTPV11]. Esta chave é temporária e a partir da release 31 do Protheus a mesma será descontinuada, sendo possível somente a configuração do novo REST 2.0.

A regra que será utilizada no momento da inicialização do REST para decidir se a versão 2.0 será utilizada é se a build do AppServer for igual ou superior a 19.3.1.0.* Há um recurso temporário para forçar a utilização do REST ADVPL para o caso de alguma quebra de comportamento crítica ser encontrada. Basta ligar a chave ADVPL=1 na seção [HTTPV11]. Mas vale ressaltar que ela é uma chave para ser utilizada em caso de emergência e que será descontinuada na release seguinte ao seu lançamento.

A forma mais simples de identificar qual das duas versões está em execução, é observando a mensagem que é exibida no console no momento da inicialização:

...