Isso é "antipadrão" e devo parar de usá-lo ou é um design inteligente?

Basicamente, comecei a fazer o seguinte ao criar um serviço REST:

1. HTML é solicitado
2. serviço retorna a página da web desejada, mas sem o "recurso" solicitado, por exemplo. dados
3. página da web contém JavaScript que emite solicitação AJAX para o mesmo serviço (tipo de conteúdo diferente)
4. serviço retorna os dados reais (JSON) e a página os exibe

Por um lado, parece ineficiente (2 solicitações), mas depois usei isso "desempenho não é motivo de preocupação", o que significa que o aplicativo interno de baixo tráfego e os sites são simples e carregam rápido.

A razão pela qual acabei com isso é que a página da Web pode ser quase pura Html + JavaScript e quase nenhuma coisa do lado do servidor é necessária, especialmente sem loops, para criar tabelas e coisas assim (que eu acho muito feia em comparação com coisas como slickgrid), por exemplo, separação de dados e exibição.

Agora, antes de começar a usar isso, é uma boa ideia ou devo parar de fazê-lo?

Se você solicitar um recurso e ele não contiver os dados, não será um serviço REST. O serviço que fornece os dados reais em json pode ser, mas a parte HTML não é. Para um aplicativo da web, isso não importa.

A técnica funciona, mas você precisa estar ciente de suas limitações:

1. Os mecanismos de pesquisa não interpretam JavaScript, portanto, sites implementados assim não serão indexáveis ​​pelo Google e similares. Para aplicação interna, isso não importa; para um público, isso importaria muito.
2. Usuários com necessidades especiais (como aqueles que usam terminais Braille) usam navegadores especiais bastante limitados e podem não interpretar o JavaScript corretamente.

Eu também observaria que o código que gera o HTML é basicamente o mesmo, seja ele executado no lado do servidor ou no lado do cliente. Você tem uma escolha muito maior de linguagens e estruturas no lado do servidor e tenho certeza de que existem vários equivalentes do slickgrid também.

Você pode, e deve, ainda manter a separação dos dados e a exibição no lado do servidor. O sistema de modelos pode, e deve, simplesmente levar os dados como estrutura de dados ou até json (especialmente se o serviço real estiver em um idioma diferente do sistema de modelos) e apenas expandir um modelo com esses dados.

E não, não estou pensando em PHP; é o sistema de modelos menos capaz do mercado (embora haja alguns melhores criados sobre ele). Estou pensando em Genshi ou XSLT ou algo ainda mais avançado que fornece widgets da web.

Não há nada de errado em fazer isso, desde que você tenha certeza de estruturar seu código corretamente. Você pode até servir o conteúdo estático, por exemplo, de um Apache, e não do seu serviço da web.

Essa é uma boa prática. E isso é feito o tempo todo, como o @JanHudec aponta, chamá-lo de serviço REST está errado. Mas muitos sites fazem exatamente isso pelas razões apontadas.

Eu não chamaria isso de antipadrão, o que você está descrevendo é mais ou menos um cliente gordo , não totalmente diferente de serviços como o Trello. A responsabilidade inicial do servidor é enviar o DOM e quaisquer recursos necessários para fazer o cliente funcionar. Trabalhei em projetos semelhantes em automação de data center e monitoramento de rede.

O cliente inicia como um DOM esparso, extrai alguns dados via XHR (às vezes via JSONP) e finalmente se conecta a um servidor de soquete. Um exemplo ainda mais básico seria um aplicativo de bate-papo.

A única razão para não fazer isso é que pode ser extremamente difícil de acertar. Se você estiver familiarizado com a programação funcional assíncrona e com todas as corridas e outros desafios que ela possa apresentar, não terá problemas em mantê-la. Mais importante, você não terá problemas para escrevê-lo, para que outras pessoas possam mantê-lo.

Se o pensamento de adicionar mais recursos começar a assustá-lo, ou você começar a achar que a depuração é um pesadelo, convém considerar outros métodos de produção enquanto continua experimentando e aprendendo.

É um design válido, desde que você não esteja cavando um buraco para si mesmo. Se você tem um monte de JS aleatórios em todos os lugares, em vez de uma interface limpa, provavelmente deseja re-fatorar ou executar o projeto de maneira diferente. A maioria das funções definidas para serem executadas quando todos os recursos são carregados deve ser anônima e inserida a partir de uma interface limpa. Se não estiverem, você pode ter problemas.

como @Jan Hudec disse, sua abordagem definitivamente não pode ser chamada de REST. Embora possa ser a parte em que o cliente solicita um recurso. É melhor que o cliente lide com a parte da apresentação, como backbonefaz. Ele se comunica com o servidor REST para os recursos e os exibe usando views.

Pode ser um anti-padrão, mas acho que também é o futuro dos aplicativos da web. Em vez de mexer no JavaScript, no entanto, você deve usar pelo menos uma biblioteca de modelos. Uma solução melhor é uma estrutura MVC do lado do cliente como o AngularJS (que por acaso estou usando agora).

Para mais algumas referências, aqui está uma postagem de blog popular comparando várias estruturas, e aqui está um site que implementa o mesmo programa usando várias estruturas.

Também: os comentários de Jan Hudec sobre interação com o mecanismo de pesquisa e leitores de tela são válidos. Se você estiver trabalhando em um site de comércio eletrônico (onde o pagerank é importante), provavelmente não deseja usar estruturas do lado do cliente. Mas para aplicativos internos, essas geralmente não são preocupações.

O que você está fazendo parece bom! No entanto, se suas respostas json contiverem HTML, você estará perdendo seu tempo.

Outro ponto, porém, é que seu cliente burro provavelmente deve obter seus dados json de um projeto diferente. Você deve procurar a separação adequada entre cliente e serviço, para ter um serviço RESTful adequado