REST, подходящий для больших моделей 3NF
Поскольку идентификаторы хранилища (см. Изображение) создаются автоматически на основе идентификаторов пользователей (которые также могут создаваться автоматически и зависят от канала) и идентификаторов каналов, это может быть очень сложно сделать. Это может затруднить сохранение данных о пользователях и разговорах, особенно по ботам и каналам.
Пример ID:
Подробнее о работе идентификаторов .
Лично я бы написал свое собственное хранилище вместо (или в дополнение к) сохранения его с помощью UserState.
Чтобы записать свои данные, сделайте что-то вроде этого:
const changes = {};
const userDataToWrite = {
name: step.result,
eTag: '*',
}
// Replace 'UserId' with however you want to set the UserId
changes['UserId'] = userDataToWrite;
this.memoryStorage.write(changes);
Это сохранит документ, который выглядит следующим образом (я установил 'UserId' в 'user123':
Читать:
const userDataFromStorage = await this.memoryStorage.read(['UserId']);
userDataFromStorage будет выглядеть так:
{ UserId:
{ name: 'myName',
eTag: '"0000c700-0000-0000-0000-5c7879d30000"' } }
Вам придется управляйте пользовательскими идентификаторами самостоятельно, но это обеспечит возможность чтения данных между ботами, каналами и пользователями.
3 ответа
Я создаю интерфейс REST, который в настоящее время имеет более 250 ресурсов. К тому времени, когда я закончу, я ожидаю, что у меня будет более 1000. Это приложение ERP, которое охватывает бухгалтерский учет, инвентаризацию, продажи, затраты на рабочую силу, разработку и т. Д.
Размер или сложность отдельного ресурса напрямую не связаны в REST, но больше касается типов носителей. Я решил пойти по пути определения своего собственного типа мультимедиа, поскольку я также создаю клиент, а интерфейс не предназначен для общего пользования. Выбор лучшего типа мультимедиа для вашей ситуации, вероятно, является одной из самых сложных частей разработки интерфейса REST.
К сожалению, большинство людей, кажется, склоняются к выбору носителя / типа и выбирают общий application / 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 меняет свой формат, многие клиенты ломаются.
большинство общедоступных интерфейсов RESTful игнорируют это ограничение, и люди создают клиентов, которые тесно связаны с неопределенным контрактом. Вот почему, когда Twitter меняет свой формат, многие клиенты ломаются. большинство общедоступных интерфейсов RESTful игнорируют это ограничение, и люди создают клиентов, которые тесно связаны с неопределенным контрактом. Вот почему, когда Twitter меняет свой формат, многие клиенты ломаются.REST - это архитектурный стиль, а не представление данных. Как правило, сегодня данные представлены либо в XML, либо в формате JSON, которые прошли боевые испытания и могут легко поддерживать большие сложные модели, на которые вы ссылаетесь.
В своей наиболее простой форме REST - это просто HTTP-глаголы для управления «ресурсом». ». Представление этого ресурса может быть настолько простым или сложным, насколько вам нужно. Операции CRUD и списки являются наиболее простыми. Дополнительные, более сложные API также могут быть легко сгенерированы в этом контексте.
REST подходит для тех случаев, когда существует разумный описательный путь для описания данных, которые вы хотите получить.
REST не чувствует себя так, как RESTful, когда вы пытаетесь выполнить Это опубликовать API, НО, я хотел бы отметить, что API, которые были разработаны с использованием философии REST, были действительно успешными.
Из вашего описания вы работаете с данными, которые должны очень хорошо соответствовать REST, независимо от того, насколько сложна структура. REST не запрещает публиковать схемы, поэтому вы можете рассмотреть это также.