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

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

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

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

Основная структура REST выглядит следующим образом:

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

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

то же самое касается:

1. / ads
2. / bids
3. / users
4. / Banner
5. и т. Д.

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

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

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

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

1. community-api
2. community-website

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

1. community-core
   • Модели
   • Cronjobs
   • Автоматические рассылки (часть cronjobs)
     • Счета и т. Д.
2. community-api
   • Взаимодействие с моделями в ядре через HTTP
3. сайт сообщества.
   • Веб-сайт
   • Администратор

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

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

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

1. ядро ​​сообщества
   • Модели
2. community-api
   • Взаимодействие с моделями в основном через HTTP
3. . Бизнес сообщества.
   • Cronjobs
   • Автоматические рассылки (часть cronjobs)
     • Счета и т. Д.
4. сайт сообщества
   • Веб-сайт
   • Администратор

Мне это кажется лучше по дизайну.
_{(источник: mauserrifle.nl )}

Основные вопросы

1)

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

2)

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

3)

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

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

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

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

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

4)

Общее: Моя архитектура слишком сложна? Какие альтернативы мне следует рассмотреть?

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