API-centric

[VEV]

Товарищи...

Чет я немного недопонимаю, мозг видимо еще не дорос. Допустим, хочу сделать софтину работающую с фронтендом через API.

По сути,если проектировать REST API, то имеем простые CRUD-операции на стороне сервера. А более сложную логику реализовывать в клиенте? Что-то мне подсказывает, что если у меня будет 100 млн. записей - такой подход не проканает.

Еще есть вопрос по авторизации: допустим, использую этот OAuth2-сервер. В API других проектов каждому пользователю выделяется токен, по которому сервер авторизовывает пользователя при запросах к API. Это какой-то левый токен, или это auth_code от OAuth2-сервера?

Если кому-то попадались хорошие статьи по теме топика - буду очень благодарен за ссылки.

 

[AnrDaemon]

Количество абстрактных записей в вакууме значения не имеет.
По OAuth - читаем документацию на OAuth. Заканчиваем гадать.

 

[VEV]

@AnrDaemon,
Человек, нечего написать - лучше не писать. Счетчик постов нарабатываешь?

Допустим, у меня есть 100 млн. статей и 1 млн. авторов. Хочу вывести процент статей для каждого автора. А теперь можно прикинуть, сколько будет получаться такая инфа с сервера, и сколько она будет клиентом обрабатываться. А если клиент - мобильный телефон? А если это все еще обрабатывается фреймворком через какой-нить TG или AR? Или доктриной? 100 млн. объектов генерировать и слать по сети?

Доки по OAuth я читал. И если б там было все норм написано и проиллюстрировано - вопросов бы я не задавал. Если есть ссылка на хорошее описание - ссылку в студию.

 

[AnrDaemon]

Получаться с сервера 0,23с, обрабатываться секунды две.
Если у тебя в ТЗ прописано "считать процент" - делаешь в АПИ функцию "посчитать процент".
Размер БД значения не имеет. Вообще. Вся РАБОТА происходит на сервере, клиент занимается только отображением результатов.
Ещё раз: прежде чем задавать дурацкие вопросы типа "представь себе" - сам попробуй представить себе. А потом представь себе что ты ошибаешься. И попробуй опровергнуть это утверждение. Получилось? Ура-ура, ты прав, можно задавать вопрос на публике, есть шансы, что тебя не засмеют с порога…

Доки по OAuth ты не читал. Там всё написано и проиллюстрировано. И что за токен, и как он берётся, и куда его потом вставлять. (Подсказка: НЕ ТУДА!)

 

[VEV]

@AnrDaemon,
Ок. Сейчас на сайте порядка 30000 статей. Через TG запрашиваются все эти статьи, из каждой вытаскивается ID категории, помещается в массив, потом убираются дубликаты, по ID-шникам запрашиваются названия категорий и в итоге должен выводиться список категорий в которых есть хоть одна статья. Угадай, сколько по времени это занимает? Так что я представляю, о чем говорю.

А теперь при разработе REST API какой я должен сделать вызов, чтобы произвелась сложная обработка данных? Что в этом случае будет сущностью, что коллекцией?

По OAuth - ссылка в студию. Сейчас, по моему пониманию, если я буду использовать auth_code - выводится запрос на разрешение использования API, которое дается на определенный срок. И мне не улыбается, чтобы в один прекрасный момент пользователь сайта получил вот такую уведомлялку, ему не предназначенную.

Пока что польза от твоих ответов 0,0.

 

[fixxxer]

То, что у тебя обычно идет в параметры рендеринга html-темплейта, отдаешь json-ом, вот и всё.

 

[VEV]

@fixxxer,
Ну, это я уже понял. Просто при использовании REST у меня есть HTTP-методы (типа, GET/POST/HEAD/PUT/DELETE/....) которые выполняют CRUD-операции с сущностью или коллекцией. А как мне запросить сложную операцию с коллекцией?

 

[WMix]

а че про sql не слышал? зачем тянуть 30000 и после на пхп обрабатывать?
зачем рест если пользуешь только GET
зачем crud когда у тебя только read
а еще можно закэшить

 

[VEV]

Доброго времени, @WMix

Код писал не я, поэтому что досталось - то досталось. Отрефакторю - будет по другому

И пользуется у меня не только GET, добавление статей, их обновление тоже через API. Мне немного не понятно формирование запросов к API. Вот допустим,
GET /article - список статей.
GET /article/1 - первая статья
POST /article - создание новой статьи и т.д.

и сущности у меня соответственно articles и authors.
И вот, теперь надо получить статистику по авторам. Что и как запрашивать - что-то не догоню.
Т.к. срезы нужны разные - заранее считать и хранить в БД не вариант. Т.е. только просчитывать в реале. Пересылать сырые данные на клиента для обработки - слишком много инфы придется пересылать. Нужно обрабатывать на сервере. Но это ж не простая CRUD-операция, и как ее запросить с сервера, оставаясь в рамках REST - не понятно.

 

[fixxxer]

Если ты так уперся в rest-пуризм - возьми json-rpc, там таких проблем нет

А с точки зрения rest, GET это все, что угодно, что не меняет основные данные. Всякие вспомогательные данные - типа кэшей - за данные не считаются. Можешь спокойно делать get /stats/by-author и не трахать мозг =)

 

[WMix]

ты перепрыгнул, одно дело апи для статей другое для "статистики авторов"
то что написано делает одну задачу, тебе на сколько понимаю нужно сделать ОТДЕЛЬНО другую
которая на GET /authors вернет по минимуму процент статей на автора
нет там crud там только cRud, обычный select

 

[VEV]

Этот процент нужно считать. Но он не всегда нужен, поэтому считать его всегда смысла нет. По идее, его надо бы запрашивать как-то отдельно.

 

[WMix]

колво_статей_автора / колво_статей_или_то_что_сто_процентов * 100

 

[VEV]

... Можешь спокойно делать get /stats/by-author и не трахать мозг =)

Разумное зерно в этом есть. Но, обозначенный URL должен вернуть коллекцию. Т.е. по сути, нужно будет для авторов создавать еще один класс сущности, который будет содержать только нужную статистику?

 

[VEV]

колво_статей_автора / колво_статей_или_то_что_сто_процентов * 100

Вот видишь, для этой формулы как минимум нужно сделать запрос в другую таблицу, чтоб узнать количество статей. Да и вычисления могут быть гораздо сложнее, и задействовать более, чем 2 таблицы. Например, когда СЕОшники/аналитики просят что-то посчитать на сайте... %)

 

[AnrDaemon]

@AnrDaemon,
Ок. Сейчас на сайте порядка 30000 статей. Через TG запрашиваются все эти статьи, из каждой вытаскивается ID категории, помещается в массив, потом убираются дубликаты

Какой дебил это проектировал?…

 

[WMix]

да, такое бывает и даже чаще чем 1 запрос. тебе нужно 2. сначала общая цифра а после группируя по автору с использованием этой цифры
и да это отдельная сущность или аттрибут автора и поправкой в операции read

 

[AnrDaemon]

Этот процент нужно считать. Но он не всегда нужен, поэтому считать его всегда смысла нет. По идее, его надо бы запрашивать как-то отдельно.

Наконец-то ты начинаешь думать. Ещё чуть-чуть, и мыслительный процесс дойдёт до мозга, в котором наконец появится мысль, что пересчитывать статистику на каждый запрос нет смысла, проще считать её асинхронно, сохранять вычисленное значение и отдавать уже его по запросу. Доли секунды на запрос и сколько там JS будет париться с его обработкой на клиенте.

 

[VEV]

@AnrDaemon,
Чел, я тебе еще раз говорю, у меня срезов разных до хреновой тучи и чуть ли не каждый день просят сделать новый. Хранить их где-либо вообще не реально. Плюс, данные по которым надо делать срезы, обновляются в среднем раз в минуту. Смысл их хранить?

 

[AnrDaemon]

А ты не пробовал анализировать то, что тебя просят сделать?
Может, пора уже не отмахиваться от советов, а задуматься над архитектурой своего приложения, если у тебя что ни день то пятница перед дедлайном?
Может, ты что-то в корне неправильно делаешь? И надо пересмотреть всё приложение в целом, чтобы не возникало таких вот мелких вопросов постоянно?