O endpoint HTML definitivo das APIs, conforme especificado no WS, ficou como api.addressforall.org/v1.htm/*. A ideia é que seu resultado seja exatamente o mesmo que o JSON. E rigorosamente isso: qualquer formulário ou interface diferenciado, principalmente quando do uso de múltipliplas APIs na mesma página, não poderá ter esse mesmo endpoint, passa a ser parte integrante do Portal, não da API.
Quanto à correspondência entre carga JSON e sua visualização HTML, como API's JSON são acessadas por um público diferenciado e mais ciente da necessidade ou não de "baixar todos os dados ou paginar", não se pode levar a ferro e fogo essa correspondência. O ideal é:
-
manter a navegabilidade entre páginas HTML desses endpoints especiais, o que inclui "funcionar com botão BACK do navegador";
-
oferecer recursos para que o usuário decida se quer navegar de forma pagina (com apenas amostragem de dados) da ou não. A decisão do usuário poderia ser carregada pela URL (parâmetro GET) ou por uma cookie.
-
não permitir que o usuário ultrapasse extremos: sempre paginar quando for muita coisa, o HTML não é um recurso de publicação de dados, antes, é um recurso de "help" para as APIs.
Tendo em vista tais considerações sugere-se a seguinte arquitetura e mudanças na estrutura da carga de página:
-
o JSON da API não virá de chamada, mas pré-carregado na página, o servidor faz a chamada da API JSON e devolve o resultado como parte da carga do HTML.
-
o servidor toma a liberdade de limitar casos de uma lista de cache de APIs onde o count ultrapassa limites.
-
os parâmetros adicionais (cookie e variavel get) são também gerenciados pelo Javascript
-
o Javascript permite recarga dos dados apenas em caso
O endpoint HTML definitivo das APIs, conforme especificado no WS, ficou como
api.addressforall.org/v1.htm/*. A ideia é que seu resultado seja exatamente o mesmo que o JSON. E rigorosamente isso: qualquer formulário ou interface diferenciado, principalmente quando do uso de múltipliplas APIs na mesma página, não poderá ter esse mesmo endpoint, passa a ser parte integrante do Portal, não da API.Quanto à correspondência entre carga JSON e sua visualização HTML, como API's JSON são acessadas por um público diferenciado e mais ciente da necessidade ou não de "baixar todos os dados ou paginar", não se pode levar a ferro e fogo essa correspondência. O ideal é:
manter a navegabilidade entre páginas HTML desses endpoints especiais, o que inclui "funcionar com botão BACK do navegador";
oferecer recursos para que o usuário decida se quer navegar de forma pagina (com apenas amostragem de dados) da ou não. A decisão do usuário poderia ser carregada pela URL (parâmetro GET) ou por uma cookie.
não permitir que o usuário ultrapasse extremos: sempre paginar quando for muita coisa, o HTML não é um recurso de publicação de dados, antes, é um recurso de "help" para as APIs.
Tendo em vista tais considerações sugere-se a seguinte arquitetura e mudanças na estrutura da carga de página:
o JSON da API não virá de chamada, mas pré-carregado na página, o servidor faz a chamada da API JSON e devolve o resultado como parte da carga do HTML.
o servidor toma a liberdade de limitar casos de uma lista de cache de APIs onde o count ultrapassa limites.
os parâmetros adicionais (cookie e variavel get) são também gerenciados pelo Javascript
o Javascript permite recarga dos dados apenas em caso