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:

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.

...

Resumindo então os modelos e os recursos de ambiente disponíveis temos a seguinte tabela:

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).

...