Histórico da Página
...
| 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.
...
Visão Geral
Import HTML Content
Conteúdo das Ferramentas