Histórico da Página
| 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:
| |||||||||||||||||||
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: charset=utf8 | Content-Type: charset=utf8 | Content-Type: charset=utf-8 | A própria lib realiza o encode para utf-8 |
| Accept: charset=utf-8 | Content-Type: charset=utf-8 | Content-Type: charset=utf-8 | A própria lib realiza o encode para utf-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 | Content-Type: charset=utf-8 | Não é realizado encode na camada de lib. |
| Accept: charset=QualquerOutroValor | Content-Type: charset=QualquerOutroValor | Content-Type: charset=utf-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:
...
Resumindo então os modelos e os recursos de ambiente disponíveis temos a seguinte tabela:
Recurso | ADVPL | tlppCore | 2.0 |
Todas as API’s WSRESTFul compiladas no RPO | Sim | Não | Sim |
Todas as API’s com Annotations compiladas no RPO | Não | Sim | Sim |
Ambiente aberto | Sim | Não | Sim |
REST MPP
Apenas para não causar confusões em análises ou discussões futuras, vale ser mencionado aqui que existe também uma instância de REST em execução na “porta única”, mais conhecida como Multi Protocol Port (MPP).
...
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas