Aviso |
---|
|
No Rest ADVPL, ao subir o appserver ele inicia o serviço com a quantidade de threads configuradas com inicial, através da chave instances. No REST 2.0, por enquanto, ele inicia o serviço sem nenhuma thread ativa, subindo a quantidade prevista como inicial somente após a primeira requisição. Este comportamento tem previsão de alteração para a lib e appservers a serem disponibilizados a partir de julho de 2021. |
Informações |
---|
|
O novo REST 2.0 contempla o retorno em chunked a partir da lib label 20201123 |
Informações |
---|
|
O REST pode responder a requisição no idioma desejado, para isso é necessário enviar o header Accept-Language, sendo que somente são aceitos os idiomas que o Protheus suporta, como pt-BR, es e en. Com isso, a resposta passa a retornar o header Content-Language. Esse recurso está disponível a partir da lib 20210628, sendo que o REST ADVPL e o REST 2.0 tem suporte a esse header. |
Informações |
---|
|
A partir da lib 20211116 o REST passará a receber o header x-erp-module, que representa o módulo do Protheus, esse header suporta os valores de módulos do Protheus válidos, como: FIN, EST, FAT, ATF. |
Informações |
---|
|
A partir da lib 20240115 o REST passará a receber o header x-erp-database, que representa a databas do Protheus, esse header precisa ser enviado no formato AAAAMMDD |
Trabalhando na evolução tecnológica dos sistemas da Totvs, o REST Server do Protheus vem passando por algumas modernizações e isso vem sendo realizado através da parceria entre os times da Tecnologia e do Framework.
...
Para entender bem essas novidades, precisamos entender quais são os componentes disponíveis, a responsabilidade de cada componente e qual time é responsável por cada um deles.
Aviso |
---|
|
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 Release 33 do Protheus (o REST convencional em ADVPL será descontinuado neste release). Para utilizar este recurso na lib 20201009 será necessário ligar a chave ADVPL=0 na seção [HTTPV11] . A partir da lib label 20210809 o REST 2.0 passará a ser utilizado por default no sistema, quando o AppServer tiver na versão igual ou superior a 19.3.1.8, mas poderá ser desligado através da mesma chave. Esta chave é temporária e a partir da release 33 do Protheus a mesma será descontinuada, sendo possível somente a configuração do novo REST 2.0. Além do pacote de lib acima é necessário também o uso do AppServer com versão igual ou superior a 19.3.1.0. Exemplo: Release menor que 12.1.33 | Release igual ou superior a 12.1.33 |
---|
Chave | Lib label 20200109 | Lib Label 20210809 |
---|
Advpl = 1 | REST 2.0 desligado | REST 2.0 desligado | REST 2.0 ligado | Advpl = 0 | REST 2.0 ligado | REST 2.0 ligado | REST 2.0 ligado | Vazia (sem a chave) | REST 2.0 desligado | REST 2.0 ligado | REST 2.0 ligado |
|
01. REST ADVPL
A partir de agora, vamos chamar nossa versão atual de REST ADVPL.
...
- 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ção | Resposta do REST ADVPL | Resposta do RestServer 2.0 | Encode retornado na resposta (REST ADVPL e REST 2.0) |
---|
Accept ContentContent-Type: charset=utf8 |
Contentutf8utf-8 | A própria lib realiza o encode para utf- |
8 Acceptcp1252 Content1252 Content1252utf-8 | A própria lib realiza o encode para |
1252 (padrão do Prothuesutf-8 |
Accept: charset=cp1252 | Content-Type: charset=cp1252 | Content-Type: charset=cp1252 | Não é realizado encode (irá utilizar o padrão do sistema) |
Accept: charset=cp1251 | Content-Type: charset=cp1251 | Content-Type: charset=cp1251 | Não é realizado encode (irá utilizar o padrão do sistema) |
Vazio | Vazio |
Contentutf8utf-8 | Não é realizado encode na camada de lib. |
AcceptAccept: charset=QualquerOutroValor | Content-Type: charset=QualquerOutroValor | Content-Type: charset= |
QualquerOutroValorutf-8 | Não é realizado encode na camada de lib. |
Aviso |
---|
|
Para o correto tratamento de encode nas apis, sugerimos o uso da função FWhttpEncode |
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.
...
A documentação completa do REST ADVPL está disponível no TDN através do seguinte endereço: https://tdn.totvs.com/display/framework/REST+ADVPL
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 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:
...