AB
Точнее, всё таки, с указанием что это RMM level 1
Ну, у меня как раз REST level 1
У тебя - что-то между 1 и 2, ближе к два, но не соответствует никаким конкретным описаниям.
Size: a a a
2021 November 18
AB
Да, там видно, что деление такое на уровни, что легко и часто попадают и не на первый, но еще не на второй.
AB
Т.е. проще уж выделять набор правил, например. Типа пути как ресурсы - правило#1 или лучше какое то сокращение (больше сокращений богу сокрашений). И по набору таких правил указывать что за дизайн АПИ
PD
Ну, идеология - это уже второй. Первый вообще ничего не регулирует.
PD
Вообще хороший заход на статью про классификации API.
AB
Идея мне нравится, но я точно в ближ. время даже за отдаленныйй черновик не возьмусь %)
PD
Ну вот (
AB
Добавим в туду лист %)
VF
Если с АПИ давать программную обёртку как пример, то кажется пофигу чего там внутри
AM
Ну, я просто не вижу особого смысла в такой классификации. Для своих проектов я просто описываю конкретные правила дизайна API.
AB
Я к этому давно склонял, еще с начала переписки про рест
AB
Ну и к идее, что если клиент сгенерирован или написан хуманом, то уже всё равно. Волновать больше будут аспекты обсервабилити.
PD
Так все эти подходы нужны 'внутри', чтобы разработчик не думал долго, как должен выглядеть entrypoint для очередной фичи.
VF
Тут типа идея была в том, что ты объявил АПИ и типа каждый как хочет, так и работает, но фактически это как-то прям плохо работает, ну потому что это не код и там сложно все это тестить, отлаживать и т.п. А с клиентом все просто, втянул либу и не переживаешь. Нужна на своем языке, взял за основу от производителя и там все посмотрел
VF
Ну вот он пусть вообще не думает о вызове, либу берет и использует
AB
Ну разрабы добавляют новые методы в апи. Соотв. как я понимаю к этому апи нужно выдать доку на требования к дизайну, которая регулирует нейминг, формат данных и т.д.
AB
И тогда разделится вот это вот всё. На идеальные концепции, определения и т.д. И на требования к конкретному АПИ, потому что вот оно, реальное, должно быть стройным в дизайне, а не "каждый дописал изменений в апи в силу своего понимания прекрасного".
PD
Ну, писать либу для каждого языка и фреймворка - дорого очень.
VF
Ну вот кажется, что мне как пользователю сервиса хотелось бы использовать сервис, а не наслаждаться его апи которое идеально соответсвует Х