
Introdução
Dando continuidade a serie de artigos sobre ReactJS + Advpl, hoje irei apresentar a configuração do servidor REST no Protheus e construir um simples Hello World para testar a comunicação. Caso você tenha interesse em ler o primeiro artigo dessa série, basta clicar aqui.
Precisamos agora configurar o Protheus para trabalhar como um servidor REST.
Configuração REST
Vamos alterar o appserver.ini incluindo as informações abaixo:
[ONSTART]
JOBS=HTTPJOB
REFRESHRATE=120
[HTTPJOB]
MAIN=HTTP_START
ENVIRONMENT=P12_25_SXLOCAL
[HTTPV11]
Enable=1
Sockets=HTTPREST
[HTTPREST]
Port=9999
IPsBind=
URIs=HTTPURI
Security=0
Public=classe/path/get1,classe2/path/gety,classe3/path/post
Notenant=classe/path/get2,classe2/path/getv,classe3/path/post2
[HTTPURI]
URL=/rest
PrepareIn=99,01
Instances=1,1
Simples explicação das informações incluídas no appserver.ini:
[ONSTART] -> Responsável por iniciar o serviço HTTPJOB no momento do start do appserver.
[HTTPJOB] -> Responsável por preparar o appserver para HTTP.
[HTTPV11] -> Ativa a funcionalidade REST no HTTP do appserver.
[HTTPREST] -> Informa ao socket REST dados como porta e segurança a ser utilizada.
[HTTPURI] -> Indica o endereço que será atendido e inicializa o ambiente para as threads.
Para mais detalhes sobre o funcionamento de cada seção e mais possibilidades recomendo estudar a documentação oficial clicando aqui.
Aplicando essas configurações acima, ao iniciar o appserver.exe em modo console será possível identificar que o servidor REST está ativo conforme imagem abaixo:

Vamos no navegador para testar a comunicação através da URL configurada, no meu caso: http://localhost:9999/rest

Que tal fazermos um “Hello World” para ser retornado em JSON e testar a comunicação REST?
Bora Codar!
Vamos criar um Hello World simples utilizando o método GET para retornar a mensagem na rota helloworld com tratativa de passagem de “Path Parameters“.
#INCLUDE "TOTVS.CH"
#INCLUDE "RESTFUL.CH"
WSRESTFUL helloworld DESCRIPTION "REST para hello world!"
WSDATA name AS STRING
WSMETHOD GET DESCRIPTION "Exemplo de retorno de entidade(s)" ;
WSSYNTAX "/helloworld || /helloworld/{name}"
END WSRESTFUL
WSMETHOD GET WSRECEIVE name WSSERVICE helloworld
Local oJson := Nil
Local cRetorno := "Hello World"
//|Defino que o retorno sera em JSON |
::SetContentType("application/json")
oJson := JsonObject():new()
//|Caso exista, utilizo o parametro enviado |
If Len(::aURLParms) > 0
cRetorno += ", " + ::aURLParms[1]
EndIf
cRetorno += "!"
oJson['result'] := cRetorno
::SetStatus(200)
::SetResponse(oJson:ToJson())
Return .T.
Uma breve explicação do que está sendo feito no código acima:
WSRESTFUL helloworld DESCRIPTION “REST para hello world!”
Cria a classe de nome “helloworld” com uma breve descrição da funcionalidade.
Essa classe será utilizada também como a rota de acesso na URL.
WSDATA name AS STRING
Declaro a propriedade “name” que poderá ser enviada via “query params“
WSMETHOD GET DESCRIPTION “Exemplo de retorno de entidade(s)” WSSYNTAX “/helloworld || /helloworld/{name}”
Declaro o método GET para a minha rota “helloworld”.
END WSRESTFUL
Finalizo a declaração da classe.
WSMETHOD GET WSRECEIVE name WSSERVICE helloworld
Nessa parte é que implementamos o código que será processado toda vez que houver uma requisição GET na rotina: http://localhost:9999/rest/helloworld
::SetContentType(“application/json”)
O “SetContentType” informa para a classe que será utilizado o formato JSON para comunicação.
Após compilar o fonte acima podemos testar o consumo desse webservice, para isso vou utilizar a ferramenta Insomnia (pode ser o Postman ou outras parecidas).
Geramos uma nova requisição do tipo GET :

Vamos agora consumir o método GET da nossa rotina /helloworld, primeiro sem passagem parametros:

Resultado:

Agora passando o meu nome como Path Parameters:

Resultado:

Com isso conseguimos realizar nosso primeiro consumo REST e agora temos certeza que o Protheus está preparado para a continuidade do nosso projeto.
Lembrando que os fontes e um exemplo do appserver.ini estão disponíveis no GitHub.
Na próxima postagem iremos trabalhar com a parte de login, não percam!
Parabéns, muito boa iniciativa.
Valeu Ramilson, vamos juntos !!
Parabéns
Tava mesmo precisando disso
Que legal Welinton !!
Acompanhe o blog pois o melhor ainda está por vir.
Public=classe/path/get1,classe2/path/gety,classe3/path/post
Notenant=classe/path/get2,classe2/path/getv,classe3/path/post2
porque precisamos dos parâmetros acima na configuração do servidor REST?
Bom dia Eduardo,
No parâmetro “Public” você deve informar os endpoints que poderão funcionar sem a necessidade de autenticação e no parâmetro “Notenant” são os endpoints que não precisam validar as empresas/filiais.
abraços
Cara que massa, estava pensando em fazer isso quando comecei a estudar criação de API em ADVPL, já vou usar teu material como referência. Abraços
Fala Sérgio!!
Fique de olho que vem muito mais por ai.