Я знаю, что у них есть приватное API на GraphQL (который сам по себе тоже неудобен, если ты пишешь не на Java/Python). И сдаётся мне, что его везде и используют, думаю оно отлично годится для примитивных клиентов («а большего мне и не надо» (с)). Сам же я использую вперемешку и официальное (старое kraken) и неофициальное, т.к. и то и другое по отдельности не дают исчерпывающей информации (хочешь превью по таймкоду — бери неофициальное, хочешь узнать статус видео recording/recorded — бери официальное). Я уже говорил, у Твича очень ужасное API, нет подробной документации с описанием возвращаемых полей (половина полей системные, опираться на них или нет?), более того одни и те же поля в разных методах API могут называются по разному, в helix вроде порядка больше, но оно неудобнее старого, т.к. там опять курсоры, а ещё требуется обязательно авторизация пользователя, которую в приложение нельзя встроить (молчу про то, что код заточенный под старое API на новое не перенести, только выкинуть). Также во всех этих вариациях API сохраняется одна и та же проблема, то что можно получить о видео за один запрос — заставляют делать за два (хочешь закладки с таймкодами в какие играли игры? сделай сто отдельных запросов). Я прекрасно понимаю, что половина всех проблем растёт из архитектуры бэкэнда, но складывается впечатление, что сегодня, мягко говоря, на разработчиков удобных функциональных клиентов под десктоп — всем наложить…
P.S.
Вообще я всё больше и больше убеждаюсь, что самое идеальное API и самая лучшая документация (да ещё с полигоном!) есть только у VK, у других по крайней мере ещё не встречал. Ну у iTunes тоже хорошо продуманное (по сравнению с Last.FM) и как раз заточенное под кэширование, хотя оно и немного урезанное по сравнению с приватным API для оф. приложения.
Впервые столкнулся с такими курсорами в API Твича, когда писал для него клиента (точнее плагин для плеера). Скажу откровенно, что очень хотелось найти того дизайнера апи и поломать ему что-нибудь. С курсорами работать крайне неудобно, вместо простых арифметических операций с оффсетами для составления запросов — с собой приходится таскать условные массивы курсоров, которые нужно всюду в коде пробрасывать. Причем нужно таскать сразу три вида курсоров: текущий, следующий, предыдущий и в коде учитывать, что предыдущего может не быть, но он может появиться. Но это ещё терпимо хоть и неудобно, настоящая же боль начинается, когда ты хочешь добавить кэширование на своей стороне, чтобы при появлении новых данных не перезапрашивать все сто страниц опять, т.к. они все прибиты к курсорам, которые непонятно при каких условиях устаревают и сервер тебе начинает возвращать страницы с курсорами, которые у тебя уже есть в кэше, но которые теперь соответствуют другим страницам с другими данными. А если ты хочешь эти данные сохранять в БД, чтобы потом пользоваться всей мощью выборки и фильтрации — то лучше забудь, я по крайней мере не смог решить ребус как затолкать в таблицу эти курсоры (три вида курсоров!), которые ещё нужно обновлять. Да, я всё понимаю, что отличаюсь от целевого пользователя, который дальше второй страницы не ходит и которому не нужен поиск и т.д. и т.п., но блин, товарищи, мы так скоро до мышей дойдём…
А почему «западная пропаганда» боится фамилий тех, кто когда то был уличен в сексуальных скандалах и скандалах, связанных с «оскорблением чувств» национальных/сексуальных меньшинств? Причем, если за этими фамилиями стоят актеры, режиссеры, продюсеры, разработчики и т.п. — то они точно также буквально вычеркиваются отовсюду и отправляются в забвение. Собственно, где бы не находились человеческие общества — в своей в сути они будут устроенны одинаково…
Не у всех есть такая возможность, по разным причинам. Я понимаю, что проект сейчас нацелен на поиск контрибьютеров и кому надо, тот соберёт себе, но простым смертным тоже хочется глянуть, что там за зверь.
P.S.
Вообще я всё больше и больше убеждаюсь, что самое идеальное API и самая лучшая документация (да ещё с полигоном!) есть только у VK, у других по крайней мере ещё не встречал. Ну у iTunes тоже хорошо продуманное (по сравнению с Last.FM) и как раз заточенное под кэширование, хотя оно и немного урезанное по сравнению с приватным API для оф. приложения.