API как ядро для веб-сайта и мобильного приложения

У меня есть разные вопросы о полной идее архитектуры. Я надеюсь, что кто-то с большим опытом может помочь мне, потому что я в значительной степени застрял во всех возможностях.

Я планирую переписать сайт сообщества. Наш клиент хочет использовать собственные мобильные приложения в будущем. Поэтому мне нужно будет принять это во внимание. Из-за этого я решил создать 100% архитектуру REST API на основе PHP framework Kohana. У меня есть choosen Кохана-за этого делает масштабирование внутреннего API на другой сервер очень легко без особых усилий. (Kohana threats внутренние url-запросы не как HTTP, поэтому в начале не так много накладных расходов и может масштабироваться до HTTP с некоторыми незначительными изменениями кода).

сначала API будет частным, но позже мы можем сделать его общедоступным, чтобы позволить больше сервисов легко подключаться к нам.

de основная структура остальных как следуйте:

1. /кошек
2. /кошки/1
3. /кошки/1/пользов.

"custom" может быть "childs", например.

же:

1. / ads
2. /заявки
3. /пользователи
4. /баннеры
5. etc..

Это идеальные объекты для API, потому что мобильное приложение определенно будет использовать всю эту функциональность.

таким образом, мы можем заключить ядро сайта-REST. Поэтому в основном я хочу сделать веб-сайт клиентом API, как и родное приложение в будущем. Это способ кажется намного проще.

что меня беспокоит, так это то, что есть гораздо больше, чем это (управление загруженными файлами, выставление счетов, автосервисы для выставления счетов, автосервисы для рекламы и так далее). Загрузка файлов через сайт к API. Это обычная практика? Если я этого не сделаю, сайт будет загружать логику, которая делает сайт больше не клиент и само приложение. Следовательно, мобильное приложение не может даже загружать, и API и веб-сайт должны знать папку Загрузки (дублирующая логика).

Я подумал о создании следующих модулей:

1. сообщество-api
2. сообщество-сайт

Api, похоже, является ядром. Но.... как насчет cronjobs и т. д.? На самом деле они не должны быть частью сайта, так как это просто "клиент". Я чувствую, что они должны взаимодействие непосредственно с моделью или API. Таким образом, в основном API становится больше похожим на шлюз к ядру и думал, что мне это нужно:

1. сообщества-основных
   • модели
   • Cronjobs
   • авто рассылки (часть cronjobs)
     • счета-фактуры и т. д.
2. сообщество-api
   • взаимодействие с моделями в ядре через HTTP
3. сообщества-сайт
   • сайт
   • Admin

основные cronjobs являются исключением из структуры REST. Они единственные, кто может изменять данные, не проходя через api. По крайней мере, это была моя идея, потому что они входят в ядро и API поверх основной.

но по дизайну это кажется просто неправильным. Манипулирование должно проходить только через API-интерфейс!

альтернатива:

1. сообщества-основных
   • модели
2. сообщество-api
   • взаимодействие с моделями в ядре через HTTP
3. общий бизнес
   • Cronjobs
   • авто рассылки (часть cronjobs)
     • счета-фактуры и т. д
4. сообщества-сайт
   • сайт
   • Admin

Это выглядит лучше по дизайну для меня. mindmap иллюстрация http://mauserrifle.nl/mindmap.jpg

Главные Вопросы

1)

должен ли cronjobs манипулировать через API или основные модели?

2)

мой счет cronjob нужен шаблон в значительной степени стиль основного сайта, конечно. Но если мой cronjob является частью бизнеса или ядра, у него не будет знаний о моем основном веб-сайте. Какой смысл это решать?

3)

мой сайт будет использовать усы в качестве движка шаблонов. (как php, так и javascript могут анализировать эти шаблоны). Я думал использовать api непосредственно для вызовов ajax, но затем понял:

сайт получает данные из api, форматирует метки времени на даты (Y-m-d) для шаблона, а затем отображает. Если я позволю javascript вызывает api напрямую, javascript также должен иметь логику (форматирование). Это дубликат кода! Похоже, единственным решением является вызов веб-сайта для ajax (который вызывает api и форматы) и возвращает отформатированный json. Я прав?

но.... простые вызовы, такие как удаление объявления, могут проходить через api напрямую (например, DELETE: /ads/1

Я получаю смесь звонков....

лучше решение для этого?

4)

в целом: мой архитектура слишком сложная? Любые альтернативы, которые я должен рассмотреть?

Я хотел бы услышать ваши отзывы!