Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Aviso
titleAtenção

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
titleChuncked

O novo REST 2.0  contempla o retorno em chunked a partir da lib label 20201123

Informações
titleIdioma

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
titleMódulo

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
titleDatabase

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.

...

Aviso
titleImportante

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 31 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 chave chave ADVPL=1 0 na seção [HTTPV11] .

A partir da lib label 20201123 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 31 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.
31
33Release igual ou superior a 12.1.
31
33
ChaveLib label 20200109Lib Label
20201123
20210809
Advpl = 1REST 2.0 desligadoREST 2.0 desligadoREST 2.0 ligado
Advpl = 0REST 2.0 ligadoREST 2.0 ligadoREST 2.0 ligado
Vazia (sem a chave)REST 2.0 desligadoREST 2.0 ligadoREST 2.0 ligado



01. REST ADVPL

A partir de agora, vamos chamar nossa versão atual de REST ADVPL.

...

 Content Contentutf88 Acceptcp1252 Content1252 Content1252 Contentutf8
RequisiçãoResposta do REST ADVPLResposta do RestServer 2.0Encode retornado na resposta (REST ADVPL e REST 2.0)
 AcceptAccept: charset=utf8Content-Type: charset=utf8Content-Type: charset=utf-8A própria lib realiza o encode para utf-
Accept: charset=utf-8Content-Type: charset=utf-8Content-Type: charset=utf-8A própria lib realiza o encode para utf-8
Accept: charset=cp1252Content-Type: charset=cp1252Content-Type: charset=cp1252Não é realizado encode (irá utilizar o padrão do sistema)
Accept: charset=cp1251Content-Type: charset=cp1251Content-Type: charset=cp1251Não é realizado encode (irá utilizar o padrão do sistema 1252 (padrão do Prothues)
VazioVazioContent-Type: charset=utf-8Não é realizado encode na camada de lib.
 AcceptAccept: charset=QualquerOutroValorContent-Type: charset=QualquerOutroValorContent-Type: charset=QualquerOutroValorutf-8Não é realizado encode na camada de lib.
Aviso
titleImportante

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.

...