У меня разные вопросы о идее полной архитектуры. Я надеюсь, что кто-то с большим опытом может помочь мне, потому что я в значительной степени застрял во всех возможностях.
Я планирую переписать веб-сайт сообщества. В будущем наш клиент хочет использовать родные мобильные приложения. Поэтому мне нужно будет принять это во внимание. Из-за этого я решил создать 100% -ную архитектуру REST API, основанную на структуре PHP Kohana. Я выбрал Kohana, потому что это значительно упрощает масштабирование внутреннего API на другом сервере без особых усилий. (Kohana угрожает внутренним url-запросам не как HTTP, поэтому в начале не так много накладных расходов и может масштабироваться до HTTP с некоторыми незначительными изменениями кода).
Сначала API будет закрыт, но позже мы можем сделать его общедоступным, чтобы позволить большему количеству услуг легко подключаться к нам.
Основная структура REST следующая:
Например, «custom» может быть «childs».
то же самое для:
Это идеальные объекты для API, потому что мобильное приложение обязательно будет использовать все эти функции.
Таким образом, мы можем заключить, что ядром сайта является REST. Поэтому в основном я хочу сделать сайт клиентом API так же, как и родным приложением в будущем. Таким образом, обслуживание кажется намного проще.
Меня беспокоит, однако, тот факт, что это намного больше (управление загруженными файлами, выставление счетов, автоматы для выставления счетов, автоматы для рекламы и т. Д.). Загрузка файлов должна проходить через веб-сайт в API. Это обычная практика? Если я этого не сделаю, веб-сайт будет загружать логику, что делает сайт не клиентом больше и самим приложением. Следовательно, мобильное приложение не может даже загрузить, и API и веб-сайт должны знать папку для загрузки (дублирующая логика).
Я думал о создании следующих модулей:
Апи кажется, что ядро. Но … как насчет cronjobs и т. Д.? На самом деле они не должны быть частью веб-сайта, так как это всего лишь «клиент». Я чувствую, что они должны взаимодействовать непосредственно с моделью или API. Таким образом, в основном API больше похож на шлюз к ядру и думал, что мне это нужно:
Ядро cronjobs является исключением из структуры REST. Они являются единственными, которые могут изменять данные, не проходя через api. По крайней мере, это была моя идея, потому что они принадлежат к ядру, и API находится поверх ядра.
Но по дизайну это кажется просто неправильным. Манипуляция должна проходить только через API!
Альтернатива:
Это выглядит лучше по дизайну для меня. Иллюстрация Mindmap http://mauserrifle.nl/mindmap.jpg
Основные вопросы
1)
Должны ли cronjobs манипулировать с помощью моделей API или Core?
2)
Мой счет-фактура cronjob, конечно же, требует шаблона, в основном, стиля основного сайта. Но если мой cronjob является частью бизнеса или ядра, он не будет знать мой основной сайт. Что имеет смысл решить это?
3)
Мой сайт будет использовать усы в качестве механизма шаблонов. (оба php и javascript могут анализировать эти шаблоны). Я думал, используя api непосредственно для вызовов ajax, но потом понял:
Сайт получает данные из api, форматирует временные метки к датам (Ymd) для шаблона и затем отображает. Если я позволю javascript сразу вызвать api, у javascript тоже должна быть логика (форматирование). Это повторяющийся код! Чувство, как единственное решение, вызывает веб-сайт для ajax (который вызывает api и форматы) и возвращает форматированный json. Я прав?
Но … простые вызовы, такие как удаление объявления, могут напрямую проходить через api (например, DELETE: / ads / 1
Я получаю смесь звонков ….
Любое лучшее решение для этого?
4)
В целом: слишком ли сложна моя архитектура? Любые альтернативы, которые я должен рассмотреть?
Я хотел бы услышать ваши отзывы!
Как только я услышал, что хорошим способом разработки веб-приложения является разработка веб-приложения, ориентированного на API . Дело в том, что если вы свяжете основную услугу с публичным API, создав приложение API-Centric, вы полностью потеряете общий смысл публичного API.
Мне это не кажется логичным.
Да, API и веб-сайт и то, что когда-либо может появиться дальше, – это отдельные вещи, и веб-сайт должен быть клиентом самого API, но поскольку это упростит все, что угодно, я считаю, что вы должны использовать RE-USE классы домена для создания и создания логики вашего сайта. Таким образом, вы можете использовать все ту же базу кода и обрабатывать все свои проблемы, включая объявления, выставление счетов и, конечно же, загрузку файлов с легкостью.
Для общедоступного API он должен быть в отдельном окне, если возможно, повторно использовать одни и те же классы домена, но с разными методами аутентификации, чтобы какая бы проблема ни возникала, это не повлияет на главную службу.
Ваши cron-задания должны использоваться только для запуска вызова через сам API, и эти вызовы должны выполняться в главном приложении (веб-сайт через API)
Если вы создаете свой веб-сайт, не повторяя себя, как и в случае использования того же кода, что и база, и обертывания веб-приложения вокруг него, вы не будете поднимать вопрос в q # 2.
То же самое относится и к вопросу номер 3. Если вы оберните веб-сайт вокруг API, веб-сайт может использовать api самостоятельно, не будучи отдельным объектом.
Ваша архитектура кажется сложной, но если вы это сделаете, это будет просто. 😉
Удачи!
REST – это всего лишь один из способов инициировать запрос. Ваш основной код, обрабатывающий запрос, не должен быть тесно связан с интерфейсом REST или HTTP. Я бы посоветовал разработать ваш REST API в качестве простого картографа для файла include или чего-то подобного. Затем ваш cron мог обойти весь REST API и просто включить файл напрямую. Отделите интерфейс запроса от кода, который выполняет фактическую обработку.