]> Sergey Matveev's repositories - stargrave-blog.git/commit
Можно ли делать REST API?
authorSergey Matveev <stargrave@stargrave.org>
Mon, 26 Jun 2023 07:51:53 +0000 (10:51 +0300)
committerSergey Matveev <stargrave@stargrave.org>
Mon, 26 Jun 2023 07:51:53 +0000 (10:51 +0300)
commitda8063a782c2f21a3ddc49f7124a334f945e563d
tree4b825dc642cb6eb9a060e54bf8d69288fbee4904
parent732ac9fb12657867b44163d51a2d7770d80c8d89
Можно ли делать REST API?

https://habr.com/ru/articles/743818/
Когда-то я старался делать web-backend с REST API. Ну чтобы все эти
красивые ресурсы в URL использовались, чтобы всё было лаконично и
понятно, под одну гребёнку. А также видел как этот REST пишут и другие.
И что почти каждый человек занимающийся подобными backend хочет REST.

Но по опыту, рано или поздно всегда всё равно придут случаи не очевидного
выбора (примеры из статьи):

    /coffee-machines/{id}/recipes/lungo/prepare ?
    /recipes/lungo/coffee-machines/{id}/prepare ?
    /coffee-machines/{id}/prepare?recipe=lungo ?
    /recipes/lungo/prepare?coffee_machine_id=<id> ?
    /prepare?coffee_machine_id=<id>&recipe=lungo ?
    /?action=prepare&coffee_machine_id=<id>&recipe=lungo ?

    GET /v1/state?user_id=<user_id>
    vs
    GET /v1/profiles?user_id=<user_id>
    GET /v1/orders?user_id=<user_id>

А если ещё хочется что чтобы и броузер мог ходить по подобным ресурсам,
то придётся ограничивать себя ещё и в выборе HTTP методов.

В итоге, уже более пяти лет я не сторонник REST, ибо по сути никогда не
видел успешных продуманных и лаконичных реализаций на нём. Если речь не
про совсем уж тривиальные задачи. И чтобы не париться, я по умолчанию
стараюсь использовать JSON-RPC (возможно поверх HTTP), где не паришься
ни о каких URL/ресурсах и просто делаешь вызовы методов, как если бы это
была обычная библиотека (собственно, делаешь RPC). И опытный коллега на
работе тоже пришёл к такому же подходу.