[Связь] OData – OData против GraphQL

GraphQL очень популярен, очень мощен, но он принципиально отличается от OData. Так что дело не в том, что какой-то из них абсолютно лучше другого.

GraphQL не является OData:Вход по гиперссылке виден.

Обсуждение в Twitter:Вход по гиперссылке виден.

Есть несколько моментов, которые я могу понять.

OData был способом сериализации SQL-оператора в URL

Трудно ограничить возможности запросов со стороны клиента.

Спецификация OData — это её сильная сторона, так же как RPC делает с RESTful. RESTful имеет свои спецификации и прост для понимания, но выразить всё сложно. RPC может выразить всё, но он слишком нестандартизирован.

OData обычно жёстче, чем состояние схемы базы данных (то есть это похоже на SQL Query), и после изменения схемы поддерживать старую версию становится сложнее.

OData предпочитает унифицированное управление, и его сложно оптимизировать для особых случаев.

OData — это как SQL Query, GraphQL — как хранимая процедура. Ты медленно пробуешь вкус.

Следовательно, эти два элемента должны сосуществовать и дополнять друг друга.

OData — это как SQL Query, GraphQL — как хранимая процедура.

OData — это как RESTful, а GraphQL — как RPC

Если вам нужна простая унификация, RESTul отличный, SQL Query достаточен, OData — хорош.

Но когда у вас есть особые ситуации и вы не можете использовать простой метод, RPC, сохранённую процедуру, GraphQL подчёркивает свою привлекательность.

Давайте рассмотрим сценарии использования обеих сторон. OData, как правило, является API для корпоративных приложений, таких как SAP. Обычно это более простой реляционный шаблон базы данных.

GraphQL — это интернет-приложение, открытый API и любой другой тип данных (например, NoSQL)

Итак, в итоге, GraphQL может выражать больше (свободнее), чем OData, а у OData есть правила (больше ограничений), чем GraphQL

Какой из них — или GraphQL для внешнего мира, или OData для внутреннего — всё зависит от проекта, который будет использовать.

Исходный текст:Вход по гиперссылке виден.