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

Question

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

• Это потому, что у вас будут клиентские приложения, созданные на платформе, в которой нет доступного Json-парсера ?

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

• Это потому, что вы чувствуете, что стандартное соглашение , что все интерфейсы RESTful следуют?

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *.

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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