Подходит ли REST для больших моделей 3NF

Question

Есть много примеров использования REST с простыми моделями данных. Например, клиент с 5 свойствами и набор заказов с 6 свойствами. Однако мне трудно представить, как использовать REST в сравнении с более сложной моделью, которую вы можете найти в государственных закупках, финансах, управлении медицинскими записями и т. Д. Существуют ли примеры использования REST в качестве основного API в среде больших больших объектов.

Возможно, я слишком много спрашиваю о подходе REST?

Answer 1

Я создаю интерфейс REST, который в настоящее время имеет более 250 ресурсов. К тому времени, когда я закончу, я ожидаю, что у меня будет более 1000. Это приложение ERP, которое охватывает бухгалтерский учет, инвентарь, продажи, затраты на оплату труда, инжиниринг и т. Д.

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

К сожалению, большинство людей, похоже, решают выбрать тип носителя / типа и выбирают универсальное приложение / json или application / xml, а затем используют загруженный javascript в браузере для интерпретации формата. [1] Это работает до тех пор, пока у вас есть единственный клиент - браузер, и вы не хотите, чтобы кто-нибудь еще использовал ваш интерфейс. Мне кажется, что это побеждает одну из главных целей REST, то есть случайное повторное использование из-за слабой связи и стандартизированных форматов.

Чтобы дополнительно объяснить, что я имею в виду, рассмотрим случай, когда вы доставляете application / json или application / xml клиентскому приложению. Как только клиентское приложение достигает этого общего формата и извлекает определенный фрагмент данных, вы создаете скрытую связь между клиентом и сервером. Если вместо этого вы используете медиа-формат «application / vnd.mycompany.myformat + xml», вы явно определяете контракт с клиентом. Это имеет огромное преимущество, когда вы вносите изменения в формат, и у вас есть возможность создать «application / vnd.mycompany.myformatV2 + xml»

Люди воспринимают REST как слабо определенный интерфейс, но на самом деле это не так. Интерфейс REST должен быть очень явным в точных типах носителей, которые он возвращает и ожидает получить. Типы носителей - это контракт. Если вы получаете application / xml и используете код клиента для вывода / Customer / Name, вы нарушаете договор.

Веб-приложения, использующие загруженный javascript, могут использовать «application / xml», поскольку детали контракта не скомпилированы в клиенте. Однако поведение клиента чрезвычайно ограничено выполнением того, что было предварительно запрограммировано в JavaScript. К сожалению, большинство общедоступных интерфейсов RESTful игнорируют это ограничение, и люди создают клиентов, которые тесно связаны с неопределенным контрактом. Вот почему, когда Twitter меняет свой формат, многие клиенты ломаются.

Answer 2

REST - это архитектурный стиль, а не представление данных. Как правило, сегодня данные представлены в виде XML или JSON, которые прошли боевые испытания и могут легко поддерживать большие сложные модели, на которые вы ссылаетесь.

В своей основной форме REST - это просто HTTP-глаголы для управления «ресурсом». Представление этого ресурса может быть настолько простым или сложным, насколько вам нужно. Операции CRUD и list являются наиболее простыми. Дополнительные, более сложные API также могут быть легко сгенерированы в этом контексте.

Answer 3

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

REST не чувствует себя таким RESTful, когда то, что вы пытаетесь сделать, это опубликовать API, НО, я бы отметил, что API, которые были разработаны с использованием философии REST, были действительно успешными.

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