Зачем нужна Одата, когда у меня есть JSON?

Я пытаюсь понять смысл Одаты и когда это имело бы смысл. Прямо сейчас, как я работаю, я использую ASP.NET и контроллер MVC / WebApi для сериализации / десериализации объектов в JSON и заставляю javascript что-то с этим делать.

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

Кто-нибудь когда-нибудь анализирует результаты запроса ODaya в JavaScript?

Может быть, OData больше о предоставлении общей конечной точки для ВСЕХ клиентов, чтобы получить подробную информацию из запроса, который JSON не предоставляет? Так что, если бы я был поставщиком данных, то я полагаю, для этого и нужны одаты?

Помогите мне понять цель и использование REST / JSON / ODATA.

JSON - это просто формат обмена данными, основанный на JavaScript.

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

Таким образом, разница между JSON с обычным REST и OData заключается в параметрах OData для манипулирования данными, например, если мы запрашиваем данные с использованием протокола OData, мы можем указать следующие параметры в URI:

• $ OrderBy
• $ сверху
• $ пропуск
• $ фильтр
• $ формат
• $ выберите

Мы можем делать проекции, связывать ресурсы и т. Д., И все эти опции доступны "из коробки". А теперь представьте, что если бы нам нужно было предоставить все эти функции в нашем собственном REST-сервисе, нам бы пришлось:

• Реализуйте их все
• Создайте наше собственное соглашение / ключевые слова для различных операций

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

Нотация JSON или JavaScript - это просто формат или стандарт для данных. Это согласованный формат для передачи чего-то вроде имени для входа в систему ИЛИ чего-то, что должно быть использовано службой REST.

Смотрите эту часть: http://en.wikipedia.org/wiki/JSON

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

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

Что касается REST, то это просто стиль архитектуры, используемый для веб-сервисов.

Смотрите эту часть: http://en.wikipedia.org/wiki/Representational_state_transfer

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

 http://www.myservice.com/specialRESTService?name=punkouter

Ответом может быть объект JSON, сигнализирующий о получении ваших данных.

{
    "name": "punkouter",
    "status": "service downloaded your data",
}

Я никогда не слышал о OData, поэтому я погуглил это:

OData построена на протоколе AtomPub и JSON, где структура Atom представляет собой конверт, содержащий данные, возвращаемые из каждого запроса OData. Запрос OData использует модель REST для всех запросов. Каждая команда REST - это HTTP-запрос POST, GET, PUT, PATCH или DELETE (сопоставление с CRUD), в котором специфика команды указана в URL.

GET: получить коллекцию сущностей (в качестве документа подачи) или отдельную сущность (в качестве входного документа).

POST: создайте новый объект из документа ввода.

PUT: обновить существующую сущность документом ввода.

PATCH: обновить существующую сущность частичным документом ввода.

УДАЛИТЬ: Удалить объект.

Похоже, OData - это что-то, написанное для расширения ванильной архитектуры стиля REST. Но похоже, что оно может дать вам некоторые дополнительные вещи, чтобы вы могли работать, вместо того, чтобы писать вещи с нуля на C # или на любом другом языке, который вы используете.

Если ваша работа подталкивает вас к использованию OData, вы все равно будете использовать JSON ... но в рамках среды / стандарта OData, написанной Microsoft et al.

Кто-нибудь когда-нибудь анализирует результаты запроса OData (SIC) в JavaScript?

Да, поскольку (звучит так) использует JSON. Было бы совершенно естественно использовать JS.

Может быть, OData больше о предоставлении общей конечной точки для ВСЕХ клиентов, чтобы получить подробную информацию из запроса, который JSON не предоставляет? Так что, если бы я был поставщиком данных, то я полагаю, для этого и есть Odata?

Odata будет предоставлять REST-сервис ... но с некоторыми добавленными стандартными сервисами поверх простой "универсальной" конечной точки REST-сервиса ... клиентам все равно, используете ли вы OData или используете свой собственный сервис C # ... до тех пор, пока поскольку ответы были в согласованном формате (например, JSON). Тем не менее, для вашей работы, возможно, они захотят использовать OData, потому что он предоставляет множество «готовых» функций.

Что касается вопроса «почему», то в книге RESTful Web API есть очень хорошее определение - по сути, OData реализует шаблон коллекции, где коллекция - это ресурс, который предоставляет список ресурсов через ссылки.

OData - это конкретная реализация сервиса RESTful со стандартным интерфейсом. Преимущество заключается в том, что вы демонстрируете API своего продукта и говорите, что он соответствует стандарту OData, поскольку пользователи, уже знакомые с OData, могут легко его использовать, не тратя много времени на чтение документации API.

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