Почему люди хотят доставлять Json и XML в качестве вывода на свои REST-интерфейсы?

Я понимаю, почему поставщики REST framework хотят предоставить поддержку для возврата как представлений на основе Json, так и представлений на основе XML, , но почему люди хотят возвращать как из одной службы?

Это потому, что у вас будут клиентские приложения, созданные на платформе с отсутствующим парсером Json?
Это потому, что вы надеетесь на более широкое внедрение интерфейса, потому что вы можете привлечь больше людей?
Это потому, что вы считаете, что это стандартное соглашение, с которым следуют все интерфейсы RESTful?

Если вы доставляете оба:

Вы избегаете пространств имен в XML, чтобы он мог быть совместим с форматом Json? Или у вас есть только одно пространство имен для всех ваших элементов данных?

Есть ли у вас какой-то стандартизованный механизм для сопоставления атрибутов и элементов в некотором согласованном формате Json или вы просто избегаете атрибутов в вашем XML?

Создаете ли вы разные конечные точки для каждого представления, или вы используете согласование контента для доставки запрошенного формата? У вас есть формат по умолчанию?

Если вы используете кеширование на редактируемых ресурсах и используете разные URL-адреса, как вы гарантируете, что когда одно представление недействительно, что другие представления также являются недействительными?

Считаете ли вы, что поддержка нескольких форматов стоит усилий?

Сводка ответов:

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

Некоторые люди хотят перенести из XML в Json, и поэтому поддержка обратной связи требуется для обратной совместимости.

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

Легко включить функцию в рамки XYZ, так почему бы и нет!

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

Ответ 1

Json часто подходит для сценариев на стороне клиента. Это суперлегкий ответ, и большая часть JavaScript-фреймворков поставляется с встроенным парсером. С другой стороны, многие серверные приложения и языки по-прежнему в значительной степени зависят от XML. Просто назовем одно: Java.

Конечно, XML может быть проанализирован с помощью JavaScript, а Java (и большая часть других языков программирования) имеет по крайней мере один парсер Json. Но на данный момент это, по-видимому, самая распространенная практика.

Говоря о теме "реализация и преимущества", я в основном работаю с Ruby, и я могу сказать, что Ruby on Rails обеспечивает возможность создания ответа Json или XML менее чем за пару секунд от того же источника. В этом случае это не проблема, и я обычно добавляю эту функцию, если я думаю, что она может быть полезна.

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

Ответ 2

Совершенно другая причина, чем то, что было сказано до сих пор -

Интерфейсы REST относятся к ресурсам, и каждый ресурс имеет идентификатор, который является URL-адресом. Просто потому, что вам нужен Ресурс в другой сериализации, будь то XML, JSON, HTML или что-то еще, мы все еще описываем один и тот же ресурс.

Итак, вместо того, чтобы указывать другой путь к XML и JSON, мы используем заголовок "Accept" для определения того, что интересует клиент. В некоторых случаях службы используют заголовок "Accept-Language" для определить, какой язык они должны использовать для своих метаданных.

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

Более подробную информацию об этих усилиях вы найдете в разделе Связанные данные, хотя это обычно относится к использованию RDF при сериализации.

update: обсуждая связь с конкретными форматами, я также рекомендую людям рассмотреть возможность чтения на Функциональные требования для библиографических записей (также FRBR), который имеет концептуальную модель отношений между "Книгой" как абстрактную "Работу", а также физический "Предмет" и уровни между ними. В библиотеке, информации и семантических веб-сообществах на FRBR был фрагмент обсуждения, в том числе, как он относится к цифровым объектам.

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

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

Ответ 3

Я написал довольно многословную статью на История REST, SOAP, POX и JSON Web Services. В основном подробно рассказывается о существовании и преимуществах различных вариантов, к сожалению, слишком долго, чтобы перечислить все содержимое здесь.

В основном XML является более подробным, более строгим и проверяемым, что делает его хорошим кандидатом на совместимость, но не таким большим программным подходом для большинства языков программирования. Он также поддерживает концепцию схемы (т.е. Метаданные о данных), которая может быть найдена в документах XSD/DTD. WSDL является расширением XSD, а также поддерживает описание веб-сервисов в бесконечных деталях (т.е. Веб-сервисах SOAP).

JSON - это более легкий, слабо типизированный текстовый формат, который, как и фактически "Serialized JSON", обеспечивает наилучшую программную пригодность для JavaScript, поскольку строка JSON может быть изначально изменена() в объект JavaScript. Отсутствие атрибутов/элементов пространств имен и концепций делает его более подходящим для большинства других языков программирования. К сожалению, он поддерживает только базовые типы: Number, String, Boolean, Object и Arrays. Это не делает его лучшим выбором для взаимодействия.

У меня есть тесты базы данных Northwind, сравнивающие их, и похоже, что XML в среднем 2x размер JSON для эквивалентного набора данных. Хотя, если ваш XML-документ содержит много разных пространств имен, полезная нагрузка может взорваться намного больше.

Ответ 4

У меня нет прямого понимания этого, поскольку я только создаю интерфейсы REST. для "внутреннего" потребления.

Я предполагаю, что поставщики публичных API - это всего лишь хеджирование своей ставки, в этой постоянно развивающейся, быстро развивающейся и конкурентной среде.

Кроме того, для hanlding относительно простых объектных моделей (что большинство из них, вероятно, есть), дополнительные усилия для обработки обоих форматов, вероятно, минимальны и, следовательно, стоят.

Ответ 5

Я думаю, что "почему люди делают это" довольно ситуативно. Если вы разрабатываете приложение для потенциального широкого круга клиентов, поддержка нескольких типов контента может повысить конкурентоспособность - как для людей, которые понимают, что означают разные типы контента, так и для людей, которые этого не делают, но, как и те, которые поддерживают современные и самые большие ключевые слова.

Некоторые причины для поддержки обоих, вероятно, более технически оправданы. Приложение может потребовать, чтобы клиенты браузера ajaxy могли захватывать информацию для страниц (для чего JSON был бы хорош), а также может потребоваться поддержка некоторых автономных клиентов API, которые могут выполнять фоновое или пакетную обработку, для которых удобнее использовать библиотеки XML.

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

В конце концов, я думаю, что ценность "стоит усилий" зависит только от того, знаете ли вы, что вы можете получить прибыль от инвестиций в поддержку нескольких типов контента. Если никто не будет использовать один из двух типов контента, зачем нужна поддержка? Конечно, они могут быть крутыми, но во многих случаях, вероятно, также подпадают под YAGNI.

Ответ 6

Я бы не слишком много читал в этом. Я думаю, что некоторые разработчики предпочитают друг друга и (особенно в зависимости от вашей структуры), довольно легко обеспечить оба.

Большинство API, которые я видел, которые используют этот подход, не беспокоят пространства имен XML

Ответ 7

Действительно, многие разработчики не понимают JSON. Я знаю, что это легкий вес и т.д., Но многие программисты не хотят проводить циклы, чтобы понять это. Они знают XML, им это нравится, и в конце концов это действительно то, что они хотят использовать. У JSON также есть эта стигма, связанная с JavaScript, и это автоматически делает ее злой для многих людей.

Поддержка обоих действительно зависит от аудитории, на которую вы пишете API, если это много бизнес-программистов, которые используют более старые технологии, то да, стоит поддерживать оба. Если вы строите его для той части технологической отрасли, которая хочет быть ближе к краю, то, возможно, не стоит поддерживать xml. Там, где я работаю, мы должны поддерживать оба, и для нас это стоит того. Мы знаем наших клиентов и то, что они хотят, и они платят нам за это.

Ответ 8

Во многих случаях служба запускалась с XMP/SOAP, это было единственным решением несколько лет назад. Однако недавно (последние 2 года или около того) JSON стал все более популярным, поэтому большинство служб решили также поддерживать JSON, и поскольку у них уже был интерфейс XML, он просто сохранил его

Ответ 9

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

Из опыта, разработчики Java и С#, как способность иметь XML, отраженный в их объектах; это создает эффект эйфории, создающий статическую типизацию, когда вещи не могут ошибаться, поскольку JSON более подвержен динамическому поведению (т.е. мистицизму или lispism).

Программисты PHP и Ruby, как правило, не заботятся.

Разработчики AJAX предпочитают JSON, поскольку eval() является их парсером (который встроен и быстро).

Ответ 10

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

Так как некоторые из моих клиентов будут мобильными приложениями, JSON удовлетворяет им, то для обработки JSON требуется сильная вычислительная мощность по сравнению с XML.
Некоторые из моих клиентов будут веб-страницами с JavaScript. Поскольку JSON является гражданином первого класса в Java Script, и поскольку мы не можем быть уверены в вычислительной мощности системы, в которой работает браузер, JSON имеет прекрасный смысл.
Другие клиенты - это компоненты на стороне сервера, и они могут легко обрабатывать XML, и поскольку разработчики этой команды знакомы с XML, они предпочитают XML.

Следовательно, с этим соединением клиентов для моей службы как JSON, так и XML имеют смысл.

Мы используем заголовок accept для определения типа ответа на возврат. И использование Джерси с Джексоном делает его очень легким. Никакой специальной кодировки, необходимой для обработки каждого отдельно. Мы не используем пространства имен и не используем атрибуты.