Зависит от задач которые это апи будет решать. Все что угодно может быть, от простых http запросов до каких нибудь RabbitMQ

gRPC в пайтоне не очень удобно юзать. Юзай REST, что тебе мешает?

RPC и REST это как бы разные вещи, первое про удаленный вызов процедур второе про доступ к данным, но на практике я встречал самопальное xml апи для которого soap использовался как транспорт (в соапе была только одна процедура которая принимала специально собранный xml как строку и потом ее кто то парсил) так что уже ни чему не удивляюсь)

https://github.com/nameko/nameko

А в чем заключается коммуникация? Что надо делать? От этого зависит и как связывать.

Дела давно минувших дней

(в соапе была только одна процедура которая принимала специально собранный xml как строку и потом ее кто то парсил)

Это известная спецолимпиада среди разработчиков SOAP-сервисов: вместо нормального API они делают одну «универсальную» операцию со схемой xsd:any или xsd:string и через хитро закрученную жопу это парсят. Особая номинация, если они в такой XML пихают внутрь другой формат представления данных, естественно придуманный ими самими, на худой конец JSON в base64 тоже подойдёт. Бонусом идёт цифровая подпись на коленке, а не через W3C-совместимую имплементацию.

REST повсеместно используется для RPC, у тебя какие-то надуманные проблемы. Впрочем, если данные совсем не нужны, требуется исключительно RPC, то лучше чистый JSON API. Но в реальности всегда нужно и то и другое.

А кролика лорчую. Не знаю чего именно пытается добиться автор, но в среднем по больнице это хорошее решение.

REST повсеместно используется для RPC

Так же как и мой пример с xml завернутым как строка в соап, но это не пример для подражания.

у тебя какие-то надуманные проблемы.

У меня нет проблем, я привык к тому что люди используют термины не понимая что они означают.

Впрочем, если данные совсем не нужны, требуется исключительно RPC, то лучше чистый JSON API. Но в реальности всегда нужно и то и другое.

Нормальные люди проектируют апи под задачу и не забивают голову всякими базвордами без необходимости и формат данных зачастую не самое главное. Есть еще такие вещи как стейтлес или нет (а REST по определению должен быть стейтлес), идемпотентность и тд и тп. Про тестирование можно вспомнить, RPC и REST требуют немного разных тестов, семантика, удобство вкуривания документации, возможность решения типичных задач за минимальное количество запросов к апи…

А так, на практике, рестом называют все что угодно просто потому что другого не знают, а рест апи звучит умнее чем просто апи, остается только смириться с этим.

А кролика лорчую. Не знаю чего именно пытается добиться автор, но в среднем по больнице это хорошее решение.

Но кролик это асинхронное апи, опять же непонятно какая задача.

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

ну или это не очень мс по своей природе.

я привык к тому что люди используют термины не понимая что они означают

Это когда прокси называют «VPN», например. А для того, что называют REST просто нет более подходящего термина.

Нормальные люди проектируют апи под задачу и не забивают голову всякими базвордами

И тут же сам начал тереть за баззворды, лол.

Есть еще такие вещи как стейтлес или нет (а REST по определению должен быть стейтлес), идемпотентность

Только с реальностью это плохо бьётся.

рестом называют все что угодно

Используешь стандартные HTTP статус-коды, заголовки, идентифицируешь ресурсы с помощью урлов etc. — то есть пользуешься возможностями протокола как частью твоего API, а не просто юзаешь его в качестве транспорта, в этом основной смысл. Оригинальная концепция as is давно устарела, сейчас приложения гораздо сложнее, бекенды делают куда больше чем просто раздают и модифицируют документики.

Можешь называть это Web API, если тебе больше нравится, но сути это не меняет.

По сути спор в том, чтобы быть педантами и похоронить термин, обозначающий устаревшую концепцию, с помощью которой ничего кроме простейшего CRUD сегодня не построишь, либо плюнуть на эту концепцию и называть так любое HTTP-savvy Web API (т.е. противоположность JSON API), как большинство и поступает.

И тут же сам начал тереть за баззворды, лол.

Так это стало бесполезным базвордом.

По сути спор в том, чтобы быть педантами и похоронить термин, обозначающий устаревшую концепцию, с помощью которой ничего кроме простейшего CRUD сегодня не построишь

Она не то что бы устарела, просто рестом называют все подряд и оригинальный смысл потерялся. Если ко мне подойдут и попросят реализовать интеграцию с сервисом с рест апи мне вот это «рест» вообще ни о чем не скажет, там может быть все что угодно.

Так что термин смело можно хоронить, на практике в 99% случаев он не несет в себе ни какой смысловой нагрузки.

либо плюнуть на эту концепцию и называть так любое HTTP-savvy Web API (т.е. противоположность JSON API), как большинство и поступает.

Не понимаю в чем проблема просто называть это API, в термине JSON API то же не много смысла, ну он типо говорит о том что там будет JSON и все, даже не факт что там HTTP используют как транспорт. Сравни это с терминами SOAP или GraphQL которые несут в себе огромное количество инфы. И то в случае с SOAP могут быть сюрпризы.

просто называть это API

Я и называю это Web API, в принципе. Но в большинстве случаев, это будет REST-like, и примерно никогда RESTful. Так что не вижу проблемы и в том, чтобы отбросить формальности и просто звать это REST.

Так что не вижу проблемы и в том, чтобы отбросить формальности и просто звать это REST.

А зачем если это не рест? И даже в случае с REST-like одному тебе известно, что в твоем апи будет взято от рест, причем может быть так что вообще ничего)

REST повсеместно используется для RPC

При том что для RPC он ничерта нормально не подходит.

причем может быть так что вообще ничего)

Тогда это и не REST-like.

Ключевое:

HTTP-savvy

стандартные HTTP статус-коды, заголовки, идентифицируешь ресурсы с помощью урлов

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

Строго говоря, REST вообще ни для чего кроме тупого круда не подходит.

Ты бы лучше тред читал, а не на первое сообщение отвечал. Авось осмысленный диалог бы получился.

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

А теперь представь что кроме нас есть еще миллион обезьян которые говнокодят свое рест апи и у каждого свое понимание что это такое.

Принципов совсем немного, я ничего не выбирал, реальность выбрала за меня.

Принципы REST (копипаста из Википедии):

• Client–server architecture — очевидно и банально, вопросов нет.
• Statelessness, Cacheability — в целом не реалистично, но «конкретная точка или даже участок у нас может быть и stateless, с нормальным кешированием».
• Layered system — при нормальной архитектуре без проблем вообще.
• Uniform interface — собственно, за счёт HTTP, ​на чём я и сделал акцент.

Так какие ключевые фичи я «определил»? Да никаких. Я частично отбросил лишь один не реалистичный, а второй отпал вместе с ним.

Мне кажется наш разговор заходит в тупик. Даже в случае с HTTP на протокол частенько кладут болт, например апдейт должен делаться через PUT, но на практике все юзают только GET и POST и различают их исключительно по способу передачи параметров. DELETE вообще не могу вспомнить что бы где нибудь видел на практике.

И это с HTTP у которого есть стандарт, а не абстрактная архитектурная модель как в случае с рест.

Просто вдумайся, рест на столько по разному говнокодят что пришлось вводить термин RESTful для тех у кого настоящий REST. Ну и о каком общем понимании REST-like может идти речь в таких условиях?

Если у тебя цель любыми способами натянуть на свое апи термин REST просто что бы было или что бы выпендриваться перед манагерами то ок, если цель сообщить полезную инфу тем кто будет пользоваться твоим апи то слово REST можно выкинуть, оно бесполезно.

Можно зайти дальше, приняв за факт, что «95% людей — идиоты», признать отсутсвие common sense как такового. Просто потому, что любая концепция сложнее «это стул, на нём сидят, это стол, на нём едят» периродически вызывает у людей затруднения. Ещё полшажка и можно отменять даже письменность. Достаточно заглянуть в комментарии на ютубе, чтобы понять, что она тоже утратила всякий смысл.

Да, ты в целом прав, но чрезмерно утрируешь.

Допустим мне просто не повезло слишком часто сталкиваться с говнокодом но вот сам факт существования термина RESTful как бы намекает что тут что то не так.

существования термина RESTful

Не ручаюсь, но я уверен, что он существовал изначально.

Не REST-full же и не complete. Просто производное от REST прилагательное.

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

Не ручаюсь, но я уверен, что он существовал изначально.

Точно не изначально, вот откуда все началось: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Автор ни разу не использовал прилагательное. И что?

Suffix

-ful

Used to form adjectives from nouns. Full of, tending to, or thoroughly possessing the quality expressed by the noun.

Antonyms

-less

Мне кажется это игра слов.

Почему нету SOAPful например?

SOAPful and RESTful SOA: co-existing in the enterprise

2006 год

https://www.zdnet.com/article/soapful-and-restful-soa-co-existing-in-the-enterprise/

Просто звучит тупо, наверное.

Ну ладно, по этому пункту убедил.

QQ-же.

Ты там собираешься по своей поделке инфу подвозить, или как партизан молчать?

GRPC, OpenAPI, AMPQ. В первую очередь нужно определить, что там за запросы. Как они поступают. Как должны обрабатываться. По очереди ли. Допустимо ли дублирование сервисов и так далее. В общем давай инфу подвози.

Если тебе вообще пофигу, лишь бы было, то GRPC. Там нагенерить можно и готово. Правда как он там с Питхоном дружит, хз. Мне пофиг.

Thrift

И все это парсят угребищным gsoap :D

Всем спасибо за ответы!