Comments 15
Повторение, мать учения, пересказали hateoas.
0
1. Эти ссылки из ответа кто-то реально использует? По-моему на них не особо удобно ориентироваться.
2. Везде пишут, что рефлексия это дорого, а у него на сервере используется в каждом запросе в public static dynamic ToDynamic(this object value).
2. Везде пишут, что рефлексия это дорого, а у него на сервере используется в каждом запросе в public static dynamic ToDynamic(this object value).
+2
1. Какие именно ссылки, уточните, пожалуйста
2. «Зачем нам кредит доверия, если никогда его не тратить?» © кто-то из топ-менеджмента Firefox. Дорого, но ведь оно того стоит? А как бы вы сделали на его месте?
2. «Зачем нам кредит доверия, если никогда его не тратить?» © кто-то из топ-менеджмента Firefox. Дорого, но ведь оно того стоит? А как бы вы сделали на его месте?
0
1. эти
2. Не знаю, по обстоятельствам.
"_links" : {
"self" : { "href" : "http://herobook/profiles?index=0" },
"next" : { "href" : "http://herobook/profiles?index=5" },
"last" : { "href" : "http://herobook/profiles?index=220" }
2. Не знаю, по обстоятельствам.
+1
1. По поводу ссылок есть вот такое мнение: intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html (ну и остальные ссылки в этом блоге тоже любопытны).
0
GraphQL решает похожие проблемы с управлением объемом выборки, но относительно стандартизированным путём.
Не в курсе, впрочем, если под .net graphQL сервер
0
Зато у GraphQL проблемы с кэшированием тк в основном все библиотеки предлагаю использовать неидемпотентный POST запрос. Получить преимущества от многоуровневой системы с кэширующим proxy (как описано в статье) становится намного сложнее.
Может у кого есть хорошие практики как это решается?
0
Не совсем понимаю — в чем проблема с POST запросами — это запросы на изменение. Что тут кэшировать? Запросы на чтение делаются через GET (http://graphql.org/learn/serving-over-http/). Да, кэширование для HTTP, наверное, не подойдет, но есть специализированные решения.
Про кэширование: graphql.org/learn/caching
В целом: предлагают клиентам самими делать нужное кэширование.
Про кэширование: graphql.org/learn/caching
В целом: предлагают клиентам самими делать нужное кэширование.
0
+ OData.
0
ИМО, REST умер, как технология, года 3 как.
Зачем вспоминать о ней сейчас?
Зачем вспоминать о ней сейчас?
-2
чойта он умер?
0
Расскажите, какая архитектура сейчас в мейнстриме, по-вашему?
0
Ну — как умер. Тьма API у сервисов построена как REST, а значит REST жив. Facebook, Instagram, Google,…
Другой вопрос, что есть более перспективные технологии — разные, да хоть GraphQL. Realtime API появляются. Да много чего напридумывали для специфических задач и исправления недостатков REST.
Стандарта REST особенно не сформировалось — как ограничивать выборку полей ресурса, как фильтрацию/отбор делать, и тп.
Другой вопрос, что есть более перспективные технологии — разные, да хоть GraphQL. Realtime API появляются. Да много чего напридумывали для специфических задач и исправления недостатков REST.
Стандарта REST особенно не сформировалось — как ограничивать выборку полей ресурса, как фильтрацию/отбор делать, и тп.
0
Sign up to leave a comment.
REST в реальном мире и практика гипермедиа