From da8063a782c2f21a3ddc49f7124a334f945e563d Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Mon, 26 Jun 2023 10:51:53 +0300 Subject: [PATCH] =?utf8?q?=D0=9C=D0=BE=D0=B6=D0=BD=D0=BE=20=D0=BB=D0=B8=20?= =?utf8?q?=D0=B4=D0=B5=D0=BB=D0=B0=D1=82=D1=8C=20REST=20API=3F?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit 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= ? /prepare?coffee_machine_id=&recipe=lungo ? /?action=prepare&coffee_machine_id=&recipe=lungo ? GET /v1/state?user_id= vs GET /v1/profiles?user_id= GET /v1/orders?user_id= А если ещё хочется что чтобы и броузер мог ходить по подобным ресурсам, то придётся ограничивать себя ещё и в выборе HTTP методов. В итоге, уже более пяти лет я не сторонник REST, ибо по сути никогда не видел успешных продуманных и лаконичных реализаций на нём. Если речь не про совсем уж тривиальные задачи. И чтобы не париться, я по умолчанию стараюсь использовать JSON-RPC (возможно поверх HTTP), где не паришься ни о каких URL/ресурсах и просто делаешь вызовы методов, как если бы это была обычная библиотека (собственно, делаешь RPC). И опытный коллега на работе тоже пришёл к такому же подходу. -- 2.48.1