Насколько правильно использовать RESTful API сервис для "внутренней" работы сайта? Мол, отправль сообщение от того-то тому-то. Дай список постов этого пользователя. Мне нужна динамика (ajax), поэтому и копаю в сторону rest
Антон, "была" если только в отсутствии поддержки новых фич, которые в общем можно и прикрутить, а так он жив, и, видимо, будет жить, чему я невероятно рад
Я заменил это в composer.json, выполнил composer update, удалил из depend всё что там было (то расширение) и бутстрап вообще слетел. Его подключать надо как-то?
KBA3, конечно. С питоном не работал, но это не суть вообще. Вам нужен сервер (я полагаю, он есть), на нем нужна любая БД, стандарт MySQL. Туда бот записывает известных ему юзеров и там же хранит их репутацию и вообще что угодно о них, что вы хотите реализовать.
Извините что не даю прямого ответа, но насколько мне известно поисковики редиректы не любят от слова совсем и могу как минимум сильно опустить сайт в выдаче, как максимум черные списки. Зачем вам старый?
А обязательно должна связь существовать на уровне MySQL? То есть индексы, внешние ключи и все дела. Я сейчас попробовал просто код этот и вроде всё работает. (я в связях БД не очень)
Дмитрий, то есть все 3 способа имеют право на существование. Но не будет ли "работа с 2 моделями в контроллере" нарушать принцип (точнее, смысл) MVC архитектуры? Для наглядности я распишу что имел ввиду:
Таблица Users:
user_id
Прочие поля
Таблица Users_info:
info_id
user_id (к какому пользователю принадлежит)
Прочие поля
А в контроллере получать user_id, а затем из 2 модели users_info выдергивать нужную запись. Мне кажется всё-таки правильнее переместить всю эту логику в модели.
(точнее, я где-то об этом читал)
Забыл упомянуть, я не то, чтобы JOIN делал, я просто в одной таблице делал столбец принадлежности к другой. Ну вроде как есть users с users_id, есть его инфа в таблице users_info, в которой в каждой строке есть столбец owner_id. Вот это мне кажется не очень верным