API como núcleo de um site e aplicativo móvel

Tenho dúvidas diferentes sobre uma idéia de arquitetura completa. Espero que alguém com grande experiência possa me ajudar porque estou muito atrapalhado em todas as possibilidades.

Estou planejando rewrite um site da comunidade. Nosso cliente quer usar aplicativos móveis nativos no futuro. Então, eu precisarei levar isso em consideração. Por isso, decidi criar uma arquitetura de API 100% REST baseada no framework PHP Kohana. Eu escolhi o Kohana porque isso faz com que a escala da API interna seja escalada para outro servidor com muita facilidade sem muito esforço extra. (As solicitações de url interna de ameaças Kohana não são HTTP, portanto, não há muito sobrecarga no início e podem escalar para HTTP com algumas pequenas alterações de código).

Em primeiro lugar, a API será privada, mas, mais tarde, poderemos torná-lo público para permitir que mais serviços se conectem facilmente.

A estrutura REST básica é a seguinte:

  1. /gatos
  2. / gatos / 1
  3. / cats / 1 / custom

‘custom’ pode ser ‘childs’, por exemplo.

o mesmo vale para:

  1. /Publicidades
  2. / lances
  3. /Comercial
  4. / banners
  5. etc.

Estas são entidades perfeitas para a API porque o aplicativo móvel definitivamente usará toda essa funcionalidade.

Então podemos concluir que o núcleo do site é REST. Então, basicamente, eu quero tornar o site um cliente da API, assim como o aplicativo nativo no futuro. Desta forma, a manutenção parece muito mais fácil.

O que me preocupa é o fato de que há muito mais do que isso (gerenciando arquivos carregados, faturamento, automains para faturamento, automails para anúncios e assim por diante). Fazer o upload de arquivos precisa passar pelo site para a API. Essa prática é comum? Se eu não fizer isso, o site faria upload de lógica, o que torna o site mais nenhum cliente e o próprio aplicativo. Portanto, o aplicativo móvel não pode sequer carregar e tanto a API quanto o site precisam saber a pasta de upload (lógica duplicada).

Pensei em criar os seguintes módulos:

  1. comunidade-api
  2. site da comunidade

Api parece ser o núcleo então. Mas …. e cronjobs etc? Na verdade, eles não devem fazer parte do site, pois este é apenas um “cliente”. Eu acho que eles devem interagir diretamente com o modelo ou a API. Então, basicamente, a API é mais como uma porta de input para o núcleo e pensei que precisava disso:

  1. comunidade-núcleo
    • Modelos
    • Cronjobs
    • Auto Mailings (parte de cronjobs)
      • Faturas etc.
  2. comunidade-api
    • Interagir com modelos no núcleo através do HTTP
  3. site da comunidade
    • Local na rede Internet
    • Administrador

Os cronjobs do núcleo são uma exceção à estrutura REST. Eles são os únicos que podem mudar os dados sem passar pela api. Pelo menos essa foi a minha ideia porque eles pertencem ao núcleo e a API está no topo do núcleo.

Mas por design que parece estar errado. Manipular só deve passar pela API!

Alternativa:

  1. comunidade-núcleo
    • Modelos
  2. comunidade-api
    • Interagir com modelos no núcleo através do HTTP
  3. negócio comunitário
    • Cronjobs
    • Auto Mailings (parte de cronjobs)
      • Faturas etc.
  4. site da comunidade
    • Local na rede Internet
    • Administrador

Este olhar melhor por design para mim. Ilustração do Mindmap http://mauserrifle.nl/mindmap.jpg

Principais perguntas

1)

Os cronjobs devem manipular através dos modelos API ou Core?

2)

Minha fatura cronjob precisa de um modelo praticamente o estilo do site principal, é claro. Mas se meu cronjob for parte do negócio ou do núcleo, não terá conhecimento do meu site principal. O que faz sentido para resolver isso?

3)

Meu site usará bigodes como um mecanismo de modelo. (tanto o php quanto o javascript podem analisar esses modelos). Pensei em usar o api diretamente para chamadas ajax, mas depois percebi:

O site obtém dados de api, formata timestamps para datas (Ymd) para o modelo e depois processa. Se eu deixar javascript chamar o api diretamente, javascript também deve ter lógica (formatação). Este é um código duplicado! Parece que a única solução é ligar para o site para ajax (que chama a api e formatos) e retorna o json formatado. Estou certo?

Mas …. chamadas simples como excluir um anúncio podem passar pela api diretamente (por exemplo, DELETE: / ads / 1

Recebo uma mistura de ligações ….

Alguma solução melhor para isso?

4)

Em geral: minha arquitetura é muito complexa? Alguma alternativa que eu deveria considerar?

Eu adoraria ouvir sua opinião!

Uma vez que eu ouvi dizer que uma boa maneira de desenvolver uma aplicação web é desenvolver uma aplicação Web cinput na API . O que é, para mim, se você acoplar o serviço principal à API pública, criando uma aplicação API-Centric, você perde todo o ponto de desenvolvimento de uma API pública.

Isso não parece lógico para mim.

Sim, a API e o site e o que alguma vez virá a seguir são coisas separadas e o site deve ser um cliente para a própria API, mas como isso simplificará as coisas, acredito que você deve RE-USE as classs de domínio para construir e basear a lógica do seu site. Desta forma, você pode usar toda a mesma base de código e lidar com todos os seus problemas, incluindo anúncios, faturamento e, claro, arquivos de arquivos com facilidade.

Para a API pública, deve ser em uma checkbox separada, se possível, reutilizar as mesmas classs de domínio, mas com diferentes methods de autenticação para que qualquer problema possa ocorrer, não afetará o serviço principal.

Seu cron-jobs só deve ser usado para triggersr a chamada através da própria API e essas chamadas devem ser feitas no aplicativo principal (site através da API)

Se você construir seu site sem repetir-se, como em, usando o mesmo código que a base e envolvendo o aplicativo da web em torno dele, você não terá a questão aumentando em q # 2.

O mesmo se aplica à pergunta número 3. Se você envolver o site em torno da API, o site pode usar o próprio api sem ser uma entidade separada.

Sua arquitetura parece complexa, mas se você fizer essas coisas, será simples. 😉

Boa sorte!

REST é apenas uma maneira de iniciar uma solicitação. Seu código central que processa a solicitação não deve ser fortemente acoplado à interface REST, ou HTTP para esse assunto. Eu recomendaria projetar sua API REST como um mapeador simples para um arquivo de inclusão ou algo parecido. Seu cron poderia então ignorar toda a API REST e simplesmente include o arquivo diretamente. Separe a interface do pedido do código que faz o processamento real.

Intereting Posts