Недавно обнаружил такой баг в одном из своих проектов. Сервис должен был получать последние 50 фотографий из Instagram-аккаунта пользователя за последние 3 месяца. Для этого я использовал метод /users/user-id/media/recent, полагаясь на официальную документацию. Я решил, что 50 объектов — это не так уж и много, поэтому передал параметр count=50. Unit-тесты не покрыли то место, если у пользователя есть больше N(~36) фотографий в Instagram за последние 3 месяца. Заметил это только чуть позже, когда кейс сработал.
Начал разбираться, первое подозрение на то, что Instagram не учитывает параметр count, или документация устарела. Но всё работает верно, если count=20, например.
Но если count > N(~36), то Instagram вернет только N объектов. Ага, похоже на внутреннее ограничение Instagram, хотя, казалось бы, какая ему разница. Но, с другой стороны, разработчиков API тоже можно понять, это было сделано для того, чтобы защитить своё API от долгих запросов. Жаль только, что об этом не написано ни в одном пункте документации. Как подсказывает сообщество, этот параметр N во всех запросах разный, поэтому приходится проверять каждый свой запрос на то, чтобы ваш параметр count не превышал N. В моём запросе N был равен 36.
Остается только реализовать pagination. В Instagram API делается не при помощи limit-offset, а при помощи max_id параметра. Например, выполним запрос для получения первой пачки объектов.
/users/123456/media/recent?count=20
Если будут еще объекты, то в респонсе мы получим объект pagination с параметром next_max_id. И следующий запрос для второй страницы будет уже выглядеть следующим образом.
/users/123456/media/recent?count=20&max;_id=123456
Мораль. Хорошая документация API будет большим плюсом вашему продукту.