Árvore de páginas

Versões comparadas

Chave

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

O que é?

Uma das preocupações do REST tlppCore é manter uma flexibilidade de uso onde o usuário dessa tecnologia o usuário/cliente possa ter recursos suficientes para desenvolver seus serviços REST conforme suas necessidades.

Uma dessas flexibilidades é uma chave de configuração de uso exclusivo do desenvolvedor, onde pode informar a quantidade de conjuntos de {chave:valor} que quiser através de um JSON.


Como usar?

O nome da chave dever deverá ser userDataUserData, ela pode ser informada no INI do appserver [detalhes aqui] ou via JSON, caso opte por executar o REST via código-fonte [detalhes aqui].

O userDataUserData deve ao final ser um JSON, porém existem algumas formas de informá-lo ao server, vamos à elas:


JSON diretamente na chave

Exemplo:


userDataUserData={"exemplo":"direto na chave"}

...

Caso necessite utilizar JSON extensos, sugerimos utilizar os modos seguintes:


JSON através de um arquivo

Nesse modo será informado na chave o nome de um arquivo, na qual seu conteúdo será o JSON desejado para a configuração, vejamos:

Exemplo: (somente nome do arquivo):


userDataUserData=userDataUserData.json

No exemplo acima, o arquivo deverá estar na mesma pasta do appserver.

Exemplo: (caminho absoluto + nome do arquivo)


userDataUserData=c:\configRest\userDataUserData.json

O uso de caminho absoluto facilita na manutenção de arquivos de configuração, pois podem estar localizados em local central.


Notas

1 - A extensão do arquivo não é obrigatória ser .json, pode-se utilizar .txt.
2 - O conteúdo do arquivo deve ser um JSON válido.



Onde usar?

Essa chave pode ser usada em diversos níveis da infraestrutura do REST server, tal flexibilidade serve para ser usada conforme sua necessidade.

Considerando essa informação, pode-se então informar um userDataUserData nos seguintes níveis:

Para todos

...

1 - Podem haver configurações coexistentes entre Server e ( Thread Pool ou Slave ).
2 - Não podem haver configurações coexistentes entre Thread Pool e Slave.
3 - Se Thread Pool possuir Slave, a configuração do userDataUserData deve ser feito diretamente no Slave.
4 - A userDataUserData que estiver configurada no Thread Pool somente será considerada se não possuir Slave.

...

Devemos lembrar que, quando uma Thread Pool possuir Slaves, o atendimento à requisição de fato será feito pelo Slave e não pela Thread Pool, embora a requisição passe inicialmente pela Thread Pool, porém somente será usada para distribuição da requisição para um dos Slaves com base nas regras do [onSelect].
O atendimento será feito pela Thread Pool somente quando ele não possuir Slave configurado.



Configuração

Observem os exemplos de configuração, feitas no INI, abaixo :


Exemplo 1 (sem Slave)


[HTTPSERVER]
Enable=1
Servers=HTTP_SRV

[HTTP_SRV]
locations=HTTP_ROOT
userDataUserData={"config":"server"}

[HTTP_ROOT]
ThreadPool=THREAD_POOL

[THREAD_POOL]
userDataUserData={"config":"threadpool"}

Nesse caso, temos 2 (dois) userDataUserData configurados:

Um para o servidor todo, ou seja, de qualquer Thread teremos acesso a esse mesmo userDataUserData.

O outro para as Threads de atendimento, e todas pegarão o userDataUserData configurado na Thread Pool, no exemplo acima com o nome de [THREAD_POOL].


Exemplo 2 (com 2 Slaves)


[HTTPSERVER]
Enable=1
Servers=HTTP_SRV

[HTTP_SRV]
locations=HTTP_ROOT
userDataUserData={"config":"server"}

[HTTP_ROOT]
ThreadPool=THREAD_POOL

[THREAD_POOL]
Slaves=SLAVE_01,SLAVE_02

[SLAVE_01]
userDataUserData={"config":"slave01"}

[SLAVE_02]
userDataUserData={"config":"slave02"}

Nesse caso, temos 3 (três) userDataUserData configurados:

Um para o servidor todo, ou seja, de qualquer Thread teremos acesso a esse mesmo userDataUserData.

Os outros 2 (dois) para as Threads de atendimento, porém, cada uma de seu respectivo Slave, ou seja, se a requisição for distribuída para qualquer thread do [SLAVE_01], o conteúdo de userDataUserData será {"config":"slave01"}, caso seja distribuída para qualquer thread do [SLAVE_02], então o conteúdo de userDataUserDataserá {"config":"slave02"}


Como resgatar os valores de

...

UserData

Para obter os valores configurados em userDataUserData, temos disponível dois métodos em oRest, são eles:


oRest:getThreadPoolServerUserData()

Esse método retornará o JSON informado no userDataUserData da sessão Server, nos exemplos aqui utilizados, a sessão seria [HTTP_SRV] e seu conteúdo:

...

Esse método quando requerido, sempre retornará o valor configurado no server, independentemente de qual Thread está a execução do serviço.


Acesse sua documentação aqui


oRest:getThreadPoolUserData()

Esse método retornará o JSON informado no userDataUserData do Thread Pool, ou do Slave.

...

2 - b) Se a thread pertencer ao segundo Slave, então a sessão será de nome [SLAVE_02] e seu conteúdo:


{"config":"slave02"}


Acesse sua documentação aqui




Nota

O retorno da ambos os métodos será sempre em formato JSON.



Exemplo

No exemplo abaixo, estamos utilizando os dois métodos.

...