У меня разные вопросы по поводу полной идеи архитектуры.Я надеюсь, что кто-то с большим опытом может помочь мне, потому что я в значительной степени застреваю во всех возможностях.
Я планирую переписать сайт сообщества.Наш клиент хочет использовать нативные мобильные приложения в будущем.Поэтому мне нужно будет принять это во внимание.По этой причине я решил создать 100% REST API-архитектуру на основе PHP-фреймворка Kohana.Я выбрал Kohana, потому что это позволяет легко масштабировать внутренний API на другой сервер без особых дополнительных усилий.(Kohana угрожает внутренним URL-запросам не как HTTP, так что вначале нет больших накладных расходов и может масштабироваться до HTTP с некоторыми незначительными изменениями кода).
Сначала API будет закрытым, но позже мы можемсделайте его общедоступным, чтобы к нам легко подключалось больше сервисов.
Базовая структура REST выглядит следующим образом:
- / cats
- / cats / 1
- / cats / 1 / custom
Например, «custom» может быть «childs».
то же самое относится к:
- / ads
- / ставки
- / пользователи
- / баннеры
- и т. Д.
Это идеальные объекты для API, потому чтомобильное приложение определенно будет использовать все эти функции.
Таким образом, мы можем сделать вывод, что ядром сайта является REST.В общем, я хочу сделать сайт клиентом API, как и нативное приложение в будущем.Этот способ обслуживания кажется намного проще.
Что меня беспокоит, так это тот факт, что это намного больше (управление загруженными файлами, выставление счетов, автоматическая почта для выставления счетов, автоматическая почта для рекламы и так далее).Загрузка файлов должна проходить через сайт в API.Это обычная практика?Если я этого не сделаю, веб-сайт будет выполнять логику загрузки, что делает сайт больше не клиентским, а само приложение.Следовательно, мобильное приложение не может даже загружать, и API и веб-сайт должны знать папку загрузки (дублирующая логика).
Я думал о создании следующих модулей:
- community-api
- community-website
Тогда кажется, что Api является ядром.Но .... как насчет cronjobs и т.д?На самом деле они не должны быть частью сайта, так как это просто «клиент».Я чувствую, что они должны взаимодействовать напрямую с моделью или API.Таким образом, в основном API становится чем-то вроде шлюза к ядру, и я подумал, что мне нужно это:
- community-core
- Models
- Cronjobs
- Автоматические рассылки (часть cronjobs)
- community-api
- Взаимодействие с моделями в ядре через HTTP
- community-website
Основные cronjobs являются исключениемструктура ОТДЫХА.Они единственные, кто может изменять данные без прохождения API.По крайней мере, это была моя идея, потому что они принадлежат ядру, а API находится сверху ядра.
Но по дизайну это кажется просто неправильным.Манипулирование должно проходить только через API!
Альтернатива:
- community-core
- community-api
- Взаимодействие с моделями в ядре через HTTP
- бизнес сообщества
- Cronjobs
- Автоматическая рассылка (часть cronjobs)
- сайт сообщества
Это выглядит лучше для меня. Иллюстрация Mindmap http://mauserrifle.nl/mindmap.jpg
Основные вопросы
1)
Должны ли cronjobs манипулировать через модели API или Core?
2)
Для моего счета-фактуры нужен шаблон, в основном стиль основного веб-сайта. Но если мой cronjob является частью бизнеса или основной деятельности, он не будет знать о моем основном веб-сайте. Какой смысл решать это?
3)
Мой сайт будет использовать усы в качестве движка шаблонов. (и php, и javascript могут анализировать эти шаблоны). Я подумал об использовании api напрямую для вызовов ajax, но потом понял:
Сайт получает данные из API, форматирует временные метки в даты (Y-m-d) для шаблона и затем отображает. Если я позволю javascript вызывать api напрямую, javascript тоже должен иметь логику (форматирование). Это дублированный код! Похоже, что единственным решением является вызов веб-сайта для ajax (который вызывает API и форматы) и возвращает отформатированный JSON. Я прав?
Но .... простые вызовы, такие как удаление рекламы, могут проходить через API напрямую (например, УДАЛИТЬ: / ads / 1
Я получаю смесь звонков ....
Есть ли лучшее решение для этого?
4) * * тысяча сто сорок четыре
В целом: моя архитектура слишком сложна? Какие альтернативы я должен рассмотреть?
Буду рад услышать ваши отзывы!