Histórico da Página
...
- 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=utf8 | A própria lib realiza o encode para utf-8 |
Accept: charset=cp1252 | Content-Type: charset=1252 | Content-Type: charset=1252 | A própria lib realiza o encode para 1252 (padrão do Prothues) |
Vazio | Vazio | Content-Type: charset=utf8 | Não é realizado encode na camada de lib. |
Accept: charset=QualquerOutroValor | Content-Type: charset=QualquerOutroValor | Content-Type: charset=QualquerOutroValor | Nã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.
...