Уродливый API

[ookami_kb]

Ну, первый пункт – это просто ваши личные вкусы. По мне, так наоборот, RESTful стал чересчур модным, и его теперь пытаются запихнуть везде, хотя во многих проектах – это натягивания совы на глобус. Не говоря уж о том, что RESTful – это не только и не столько про GET/POST/PUT/DELETE.

Но остальное – это тоска и безысходность, да.

[Urvin]

Как вообще может быть, что на один и тот же запрос приходит один и тот же json, но с разными типами значений? Неужели на бэкенде стоит условие на пользователя и нужно возвращать разный json? Зачем? Как?

Да все банально, не нужно паники, из БД числовое значение может прийти в текстовом виде. Для одного пользователя может потребоваться какая-то обработка этого значения, и его обрабатывают, переводя в int. Для другого — не потребовалось, так текстом и уехало на вывод.
Выброс JSON применен без преобразования типов JSON_NUMERIC_CHECK

[cheevauva]

Разные форматы ответа в php могут быть, так как сформировать json можно из каких угодно данных. В данном случае, я предположу, что бэкенд в одном случае привел все поля к строкам, в другом случае оставил те типы, которые должны быть у полей. В любом случае это баг или кривые руки того кто писал бэкенд.

[lytican]

У меня более экзотический, но реально существующий вариант из жизни: на бэкэнде минимум 2 сервера. На одном нормальный кастинг строки в int на уровне php/mysql, на втором расширение php-intl недоустановили, либо MariaDB, либо (… и т.д.). Обычное дело при распределении нагрузки, либо по Insomnia то к одному стучишься, то к другому. При одинаковой кодовой базе. А ваш вариант мне кажется нежизнеспособным, раз автор говорит про один и тот же метод, но с разными пользователями.

[mrBarabas]

Пример: yii2 билдером из БД числа вытягиваются как строки, через актив рекордз — числами (сейчас как не знаю, но на одном проекте такое у нас когда-то было). При этом не всегда так и многое зависит от приведения к типам и строгой типизации. Описанный случай в статье — это недосмотр(баг) и отсутствие элементарной документации на апишку (где было бы указано формат возвращаемых значений) и дело тут совсем не в том, что айпи плохое, а в том, что бекенд делает люди без связки с фронтом (мобильным приложением) и это больше организационная проблема, т.к. это обычные «детские» проблемы при разработке, которые и решаются либо тестами (оптимальный вариант) или тестировщиками, которыми могут быть как и фронтендер, так и пользователи и т.д.

Кстати, такое поведение легко определить по коду бекенда, такие программисты очень любят == вместо ===. Большинство проектов из «тёплых стран» на гитхабе таким страдают.

[tcapb1]

В принципе более-менее понятно почему API в таком виде.

RESTful API — не могу сказать что это общепринятый стандарт. Порой необходимый функционал натянуть на GET/POST/PUT/DELETE — весьма нетривиальная задача.

Использование snake case не должно смущать, это стандарт основной библиотеки PHP. Несмотря на то, что сейчас в основном методы и т.д. пишутся в camelCase — то что был выбран snake_case для API — ничего удивительного. Несоответствие с заглавными буквами пожалуй тоже понимаю откуда взялось: скорее всего значения в корне прописаны программно, а значения с заглавными буквами — это какой-то select из базы, и там поля хранятся именно так.

Различный тип для числа (string и int) — PHP-шники до недавнего времени не особо запаривались с типами.

Если спец по бэкэнду работает в вашей же команде — решить вопросы с int, возвращением заголовка application/json и т.д. — это должно быть просто. Если же вы работаете с внешним API — то ожидать от него любой дичи даже если на первый взгляд всё выглядит хорошо — абсолютно нормально. Гораздо меньше шансов, что какое-то не то значение сломает ваше приложение.

[saintbyte]

классика жанра делаешь классический rest по всем канонам — потом приходят мобильшики и начинают требовать чтоб вот здесь еще и это выдавалась, подключают кого-нить по главнее и начинаешь творить такую жесть чтоб только они все отвалили. А через полгода наблюдаешь не API а какого-то мутанта а

[AndrewPiterov]

не исключено, но в моем случае, я до мобильной разработки писал более 5 лет REST/GraphQL сервисы и знаю как красиво их писать, и я бы хотел помочь выправить его API

[EireenK]

делаешь классический rest по всем канонам — потом приходят мобильшики и начинают требовать

Те, кому выполнение реальных задач важнее "классической красоты по учебнику", давно просветлели до JSON-RPC.

[apapacy]

Числа текстового типа как-то сам генерировал в своем первом приложении. Все загвоздка в том что драйвер MySQL числовые типы возвращает как строку и это было для меня самого было полной неожиданностью.
Когда используются сильные orm вроде Doctrine эта проблема уходит.

[mrBarabas]

Выше пример с yii2 привёл, сами с таким сталкивались, до 7-ки это особой проблемой не было, а потом как начали внедрять строгую типизацию оно стало серьезной проблемой.

[dmitry_dvm]

Ещё часто бывает, что если есть данные, то возвращается массив, а если нет, то пустой объект. Руки бы ломал за такое.

[apapacy]

Ксати интересный вопрос как унифнцировать массивы (если это например поле объекта) возвращать пустой массив, не возвращать ничего или возвращать null?

[AndrewPiterov]

можно null, но я бы возвращал пустой массив

[apapacy]

Пустые массивы легче потом на фронтенде обрабатывать согласен. Так как кругом идет просто перебор элеметов и не нужны эти прверки на null. Но вот если вдруг захочетс тербоания на не пустоту массива добавить (хоть при вводе значений, хоть при выводе) то тут начнутся траблы.

[arthuriantech]

RESTful — вид реализации архитектуры API, которая наилучшим образом позволяет использовать протокол HTTP. С REST нам нужно думать о приложении с точки зрения ресурсов. Определить, какие ресурсы мы хотим открыть для внешнего мира (например, tasks, customers, etc.). Используем глаголы, определенные протоколом HTTP, для выполнения CRUD операций с этими ресурсами, т.к. GET, POST, PUT, DELETE.

Я узнаю эту копипасту из блогов и статей, которые перепечатывают одно и то же друг у друга (часто — одинаковыми предложениями) не приводя ни ссылок, ни обоснований ;)

[AndrewPiterov]

я думаю, многие уже знают про REST и работали с ним, и это статья не туториал.

[constb]

REST и RPC вполне сосуществуют и дополняют друг друга и там уже в зависимости от того что за апи мы делаем, где-то лучше подходит одно, где-то другое. тут автор явно хотел сделать RPC, но не знал слышал про JSON-RPC, а вдохновлялся по-моему вообще вордпрессом :)

Upper case snake case чаще называют screaming snake case, а почему так – элементарно. в коде проще набирать простым snake case потому что для этого не нужно caps lock включать. а в upper case поля в табличке заведены в базе… ну а на клиента это выливается без попытки привести это в какой-то божеский вид, потому что «и так сойдёт»…

различные поля в ответах для разных пользователей – это интересная задачка! я бы предположил что в зависимости от какого-то свойства пользователя вызывается какая-то функция, которая превращает все значения в строки. ¯\(ツ)/¯

[nikita_dol]

А сейчас в каждом месте, где мы выполняем запросы на сервер, получая ответы, мы должны добавлять это преобразование сами:

Пакет retrofit использует dio, поэтому можно добавить Interceptor или Transformer что бы преобразовывать ответ в мапу или хидеры в application/json

Возможно будет удобнее так, чем везде заменять