Pull to refresh

Comments 11

Вы в статье упоминаете RESTful API, но у Beds24 оно не RESTful, a RPC.
Потому подход REST к ним особенно то и не применим.

интро
Легко говорить как не надо делать… первым делом (перед критикой) стараюсь не забить спросить: в каких условиях проектировалось… есть апи, есть требования бизнеса, есть сроки, и конечно же каноны и перфекционизм — и все эти вещи очень редко удается сочитать в рамках проекта.


в предмете обсуждения мало реста, а если реста мало — то это вовсе не рест )

надоело
следующий проект апи сделаю без rest-ориентации, надоело, чесслово:
— километровая документация, /users (post, get) /users/ID (get, put, delete) /users/ID/photo (get, put, delete) и т.п. проиходится описывать запрос, ответ, возможные ошибки (валидация, и т.п.), закодить, описать доку (окей, сгенерировать можно)… чтото пытался переиспользовать (одинаковые запросы\ответы) — всеравно в проекте средней величины документация распухает, а еще удобно иметь возможность тестовые запросы отправлять и т.д. и т.п… ад крс
— десятки, сотни ендпоинтов… которые нужно «адекватно» назвать, придерживаться правил нейминга и лучших практик, и т.п., за каждым ендпоинтом следить и возвращать «адекватный» http status code… ад
— частая необходимость компоновать несколько существующих ендпоинтов в 1 (економить на запросах\трафике, скорость ответа и т.п., да и просто для фронта\отладки удобней пользоваться и имплементировать)… тогда начинается боль куда ендпоинт припарковать одновременно относящийся к /users /announcements /images и конкретно к ниодному (только часть логики из каждого с предыдущих)… ад
— фильтры… по ресту это GET, оно и правда так, но проблема — длинна запроса (ключей может быть много, значений еще больше (длинна)… и визуально большой фильтр не так просто разобрать, особенно при отладке…
— и так дале… тоесть, часто, рест гдето в средине проекта все сложнее поддерживать рестом…

графкл, казалось бы, мощная замена ресту, но слишком много всего описать и связать, чтобы адекватно работало… хоть в преспективе оправдывается… но не без проблем… сложность системы в разы выше сложности бизнес-логики…

след. апи-проект делаю по тупому и лениво:
— один эндпоинт, он есть корень: /
— один метод, только POST
— запрос в виде:
{
"schema":"user", 
"action":"create",
"request": {},
}

— ответ в виде:
{
"schema":"user", 
"action":"create",
"response": {},
}


схема user описывает в себе возможные action и их запросы\ответы, все в одном месте, у меня голова не болит:
— как назвать и куда припарковать ендпоинт
— нет длинных урлов
— удобно строить структуру проекта (тупо 1 примитивный шаблон на все)
— граница отвественности (схема делает то что делает, нет пересечений)
— легко документировать

както так… надоел уже этот рест, честн.слово… сил нет )
Проблема №4 обычно возникает, когда инструкцию пишет человек с уклоном в гуманитарное мышление — никакой конкретики, сплошные приближённые понятия. Не удивлюсь, если это API писал такой же разработчик.

Однако, что касается замечаний к этому пункту, тут тоже не всё последовательно. Автор пишет, что RESTfull API не должно зависеть от предыдущего вызова, однако это всё-таки лукавство. API в абсолютном большинстве случаев подразумевает не только вывод данных, но и ввод. Входные данные по определнию способны изменить состояние системы, иначе зачем они вообще нужны? Если следовать этой идеологии до конца, следовало бы делать два API, одно полностью RESTfull, служащее только для получения информации о системе, и другое — для ввода данных. Однако, полагаю, два API вместо одного, автора обрадовали бы ещё меньше, хотя идеология бы и выполнялась.

Полагаю насчет состояния имелось в виду чуть чуть другое.
К примеру у нас есть: /post/1/comments
Получить все комментарии к публикации с ID=1
При повторном запросе мы так же ожидаем получить все комментарии, но API запомнив нас, может вернуть только новые комментарии с момента последнего запроса.
Если мы захотим только новые комментарии, то мы сами должны об этом сказать, обратившись к примеру: /post/1/comments/2453
Получить комментарии опубликованные после комментария с ID=2453

Ну, описанное вами никакого отношения к REST не имеет, насколько я могу судить.

Так же криво можно и RESTfull API написать.
UFO just landed and posted this here
Возможно это самонадеянно, но могу с большой долей уверенности сказать, откуда взялось такое апи и почему оно такое.

Есть некоторое внутреннее приложение, для которого был разработан некоторый апи, отвечающий его потребностям. В какой-то момент понадобилось сделать внешний доступ к данным системы.
Вариант1: давайте разработаем новый апи (+хх человеко-часов).
Вариант2: давайте откроем доступ к имеющемуся или его части (+yy человеко-часов).
Я думаю не нужно объяснять что xx>>yy.
Так как система коммерческая, очевидно, что главным фактором была стоимость разработки. Откуда и был сделан понятный выбор.

Например формат ответа мне вполне понятен — если id комнат содержаться отдельно (а формат запроса на это явно намекает), то дальнейший доступ через response[roomId].roomsavail существенно удобнее и в написани и в прочтении и в исполнении, чем попытка аналогичного доступа в «улучшенном» виде ответа. Я попытался это сделать однострочником, но понял, что это выходит полным провалом. Даже через цикл это выглядит странновато. Да, можно делать трансформацию ответа, можно оформить доступ через функцию. Но зачем. АПИ очевидно дает тот ответ, который нужен и удобен системе в которой он работает.
По ссылке которую вы даёте на стандарт ISO 8601 написано:
"
The hyphens can be omitted if compactness of the representation is more important than human readability, for example as in

19950204
"
Вызов АПИ будет принимать сервер, ему человекочитаемый вид данных до лампочки, а компактность — может пригодиться, запись даты и времени без знаков препинания это в рамках стандарта ISO 8601.

По оформлению документации — у них просто устаревший визуальный стиль, не вижу в этом ни чего страшного.

В целом хорошая статья. Спасибо.
Sign up to leave a comment.