IK
Gql это по сути синтаксис, который описывает протокол общения между клиентом и сервером
Size: a a a
2018 November 17
IK
А то как именно это реализовано зависит от самих разработчиков
IK
Хоть через сокеты
IK
Честно говоря, такое впечатление, что автор статьи никогда не работал с gql, так как половина cons чистой воды выдумка
NK
Автор мва эксперт консалт мастер по апи :)
NK
Как и любой консалт теоретик а не практик
NK
Имхо
NK
Его термин "так называемый рест апи (so-called rest)" выдает это
NK
Это наиболее распостраненная реализация сейчас
RB
ID:645784391
Это наиболее распостраненная реализация сейчас
Да, либо что-то среднее между его HTTP API и REST API.
NK
Как там, принцип hateos чтоли, когда стейт передается ссылками в ответе. Никогда не сталкивался с такой реализацией сервисов
RB
ID:645784391
Как там, принцип hateos чтоли, когда стейт передается ссылками в ответе. Никогда не сталкивался с такой реализацией сервисов
У нас на проекте в какой-то мере присутствует hypermedia на проекте и всё сущности и зависимости перелинкованы между собой. Т.е. клиент в каком-то приближении может построить схему ресурсов использую отправную точку. Однако взаимодействие между сервисами внутри периметра всегда пишется с использованием прямо зависимости на микросервисы.
NK
Чаще всего все что приходится использовать - версифицированый http api с его гет и пост запросами.
RB
И мобильное приложение, которое писали по нашей апишке, тоже пользовалось напрямую ресурсами :)
RB
ID:645784391
Чаще всего все что приходится использовать - версифицированый http api с его гет и пост запросами.
Угу.
NK
Впрочем он указал плюс http api - его легкое масштабирование. А для больших нагрузок это основной критерий. Потому и живет и будет жить он:)
NK
А то что серверсайд писать сложно - миф. На яве например имея описание апи сделать это дело пары дней
NK
Амазон там вообще как сервис предоставляет это
NK
Так что чистый рест и граф еще долго будут в догоняющих. Ибо и старые методы хороши
NK
Да и реализовать rpc поверх чего то еще сложно