Estou trabalhando em um novo projeto de aplicativo para iOS, no lado móvel. Algumas mudanças na arquitetura estão acontecendo e, por acaso, teremos que confiar em uma API privada customizada que será usada pelo aplicativo que estamos construindo e também por outros clientes, como um site.
A API que está sendo projetada segue o estilo Restante de operações URI e CRUD centradas em recursos mapeadas para verbos HTTP. coisas como:
GET www.example.com/books
DELETE www.example.com/books/482094
POST www.example.com/users/6793
O problema é que esse estilo geralmente leva à necessidade do cliente móvel fazer muitas solicitações para carregar uma única tela de aplicativo ou gerenciar uma ação de interface do usuário de usuário único. Isso faz com que o aplicativo fique no modo de carregamento por 8 segundos até ter tudo o que é necessário. Um aplicativo lento e sem resposta.
Os clientes móveis têm sérias limitações quando se trata de conectividade e, idealmente, devemos seguir esse tipo de regra:
1 tela == 1 chamada de API
1 gravação == 1 chamada de API.
Existem muitas situações em que isso o coloca em rota de colisão com os princípios de design do REST, por exemplo:
- digamos que seu aplicativo esteja offline por um dia e você precise sincronizar com quatro tabelas dos bancos de dados back-end e precise de uma chamada como
www.example.com/sync_everything?since=2015-07-24 - digamos que haja uma tela em que o usuário possa editar muitos de seus objetos, por exemplo, marcando tarefas em sua lista de tarefas. deve haver uma maneira de editar todos esses registros de tarefas em uma única chamada de API em lote, em vez de uma chamada de API por edição.
- digamos que exista uma tela que misture informações das tabelas db ORDER, SALESMEN e PRODUCT, eu deveria obter esses dados em uma chamada em vez de três.
o risco é que possamos acabar com a API mais tranquila que existe e também o aplicativo móvel que não responde de forma mais inútil.
O problema é que sou apenas um novo contratado e o que preciso é de algo que me ajude a argumentar, alguns artigos de fontes bem respeitadas ou algo assim. Principais players comprometendo-se com o estilo REST para seu cliente móvel (por exemplo: usando pontos finais de API agregados compostos).
Ou qualquer solução para esse problema geral. Obrigado!
Respostas:
Este é o seu problema aqui.
Você limitou seus recursos a (suponho) os modelos em seu banco de dados. Como tal, está demorando muito tempo para carregar todos esses recursos, porque seu servidor não tem um conceito de recursos que não têm uma representação no banco de dados.
Por exemplo, pode ter
que tudo precisa ser carregado para obter minha biblioteca
Isso não é um problema com o design RESTful, é realmente um anti-padrão REST. Não há absolutamente nada no REST que diga que nossos recursos devem ter um mapeamento individual com qualquer outra coisa em seu sistema, incluindo modelos de banco de dados.
A solução é criar mais recursos que correspondam melhor ao que você deseja carregar. Se você tiver cinco recursos que sempre acabam juntos, crie um novo recurso que contenha as informações desses 5 recursos.
O que você deve ter é algo como isto
que apenas carrega todos os livros para esse usuário. "my_library" não é um modelo no seu banco de dados, mas é um recurso. O servidor o cria com base nos modelos no banco de dados, mas não há mapeamento 1 para 1 e o servidor tem flexibilidade para criar esse recurso sem alterar o modelo do seu banco de dados.
Você também pode ter
nenhum deles precisa existir como modelo no banco de dados ou no espaço do domínio.
Existe um amplo conceito errôneo de que isso é algo errado, porque estruturas como o Rails ensinaram as pessoas a mapear recursos de uma a uma para modelos no espaço de domínio que mapeiam novamente de uma para uma com as linhas do banco de dados. Isso não é necessário nem recomendado.
Os recursos devem ser numerosos, baratos e leves . Deve ser fácil criá-los e eles devem ser abstraídos do seu modelo de domínio. Se você achar que precisa de um novo, basta fazer um novo. Se você tiver problemas para fazer isso, a falha de suas estruturas não é uma falha no REST.
Agora, a grande ressalva disso é se sua estrutura permite que você faça isso. Estruturas como Rails e Django, que seguiram o curso para mapear 1 para 1, a fim de "economizar seu tempo" tornam difícil fazer isso. Mas isso é uma falha nas estruturas, não no design RESTful.
Aqui está Jim Webber discutindo isso com mais detalhes (incluindo algumas escavações no Rails também!)
https://yow.eventer.com/yow-2011-1004/domain-driven-design-for-restful-systems-by-jim-webber-1047
fonte