219

Ответ на пост «Плохой API»1

Так... В общем, насколько моего понимания хватает, вкратце это разница между REST и JSON RPC.


Первый по-максимуму использует методы и коды ответа протокола HTTP в том числе для передачи информации логики API.


Второй чётко отделяет слой HTTP и слой логики API. HTTP только чтобы передать запрос-ответ. Инфа про запрос, в том числе тип операции - только в теле запроса. Инфа про ответ, в том числе код результата выполнения операции - только в теле ответа.


И то, и другое - валидные протоколы API, более или менее подходящие под разные задачи. Главное не натягивать мухи на котлеты.


Всё, зануда мод пошёл отдыхать.

Ответ на пост «Плохой API» IT юмор, Http, API, Программист, Программирование, IT, Ответ на пост, Текст

IT-юмор

6.9K поста53.2K подписчиков

Правила сообщества

Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору

Вы смотрите срез комментариев. Показать все
24
DELETED
Автор поста оценил этот комментарий

REST - не протокол. JSON RPC протокол. Сравнивать их как сравнивать тёплое с мягким.

раскрыть ветку (13)
17
Автор поста оценил этот комментарий

Некоторым даже незнание матчасти не мешает занудствовать

12
Автор поста оценил этот комментарий
всё правильно, rest это архитектурный стиль, это правила как должны выглядеть запросы. json rpc - протокол удалённого вызова процедур. и если для json-rpc есть спецификации то для rest их нету.. так что предыдущий коммент очень даже в тему, но начинающие ит-шнитки сравнивают всё и вся

json-rpc кстати никак не связан с http, это просто транспорт для него (один из)
Автор поста оценил этот комментарий

У нас есть задача - сделать API. Мы можем его сделать в стиле REST, а можем использовать протокол JSON-RPC. Что нам мешает сравнивать эти 2 подхода?

раскрыть ветку (10)
9
DELETED
Автор поста оценил этот комментарий

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

раскрыть ветку (9)
3
Автор поста оценил этот комментарий

Не ругайтесь. Вы, конечно, правы, но есть штука, которая сочетает то, о чем говорит коллега:

https://jsonapi.org/

Как раз спецификация протокола с кучей имплементаций клиентов и серверов, как реализовать API через JSON-объекты в стиле REST.

раскрыть ветку (2)
2
DELETED
Автор поста оценил этот комментарий

И. внезапно, статусы

Иллюстрация к комментарию
раскрыть ветку (1)
2
Автор поста оценил этот комментарий
Вы про то, что такого кода нет в RFC на REST? Вы верно сказали ранее, что это всего лишь стиль. В разделе 6 RFC 7321 так и сказано:

HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable.
Автор поста оценил этот комментарий

> Протокол и подход сравнивать безсмысленно


Вот ведь заладил. Я спрашиваю конкретно - почему, какой ужасный результат мы получим? На конкретном примере.


Не хочешь сравнивать протокол с подходом - ок, оберни JSON-RPC в подход. Или, наоборот, сделай прототип конкретного протокола в парадигме REST. И сравнивай.

раскрыть ветку (5)
4
DELETED
Автор поста оценил этот комментарий

Можно все апи пост-запросами сделать и с двухсотыми респонсами.  Можно есть руками с миски на полу. Варианты вполне рабочие, но не в приличном обществе.
Эту хрень еще ж поддерживать, развивать, модифицировать. И чем оно красивее и интуитивно понятней, тем легче будет работать и понимать происходящее и тебе, и твоим коллегам, и тем, кто будет на проекте после тебя.

раскрыть ветку (4)
Автор поста оценил этот комментарий

Угу. Это один фактор. А есть ещё куча других. Инфраструктура, библиотеки, требования, мониторинг, прокси, масштабирование и т.д.


Если у вас проект на 2 странички и 3,5 человека - можно, конечно, спокойно строить себе "приличное общество". Если что-то более серьезное - рекомендую всё же откладывать в сторону эмоции и взвешивать факторы прагматично.

раскрыть ветку (3)
3
DELETED
Автор поста оценил этот комментарий

Апишка лишь точка связи. Ей пофигу на все те умные слова, она практически не зависит от них.
Если на большом проекте хаос, то надо дать лидам по шее и сваливать. Или постепенно приводить в порядок при каждой итерации.

раскрыть ветку (1)
Автор поста оценил этот комментарий

А, ну ок, продолжай сваливать. Тоже стратегия.

1
Автор поста оценил этот комментарий

Нет, чувак, если у тебя огромный долгоживущий проект с множеством распределенных команд разработки, тестирования, развертывания, внедрения  и поддержки - как раз и нужно строить "приличное общество". И это чистая прагматика.

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку