Pull to refresh

Comments 22

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Выше пример с yii2 привёл, сами с таким сталкивались, до 7-ки это особой проблемой не было, а потом как начали внедрять строгую типизацию оно стало серьезной проблемой.
PDO + PDO::ATTR_EMULATE_PREPARES => false + PDO::ATTR_STRINGIFY_FETCHES => false должно решить проблему без доктрины.

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

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

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

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

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

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

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


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


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

UFO just landed and posted this here
UFO just landed and posted this here
А сейчас в каждом месте, где мы выполняем запросы на сервер, получая ответы, мы должны добавлять это преобразование сами:
Пакет retrofit использует dio, поэтому можно добавить Interceptor или Transformer что бы преобразовывать ответ в мапу или хидеры в application/json

Возможно будет удобнее так, чем везде заменять
Sign up to leave a comment.

Articles