Описание схема: Описание схем — Производство и поставка электростанций, Бензиновые и дизельные генераторы от 1 до 100 кВт. Мини ТЭЦ на базе двигателя Стирлинга.

Содержание

Описание схем

Мы сформировались в детстве, когда ваши эмоциональные потребности не были удовлетворены, и вы чувствовали боль, стыд, отчаяние. Мы искажаем ваш взгляд на себя и на мир…

— Познакомимся?
Нажимайте на значки «?», чтобы узнать больше

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

РАННИЕ ДЕЗАДАПТИВНЫЕ СХЕМЫ

18 ранних дезадаптивных схем сгруппированы в 5 категорий, или доменов. Каждый домен соответствует определенным неудовлетворенным потребностям развития:

1.Домен нарушения связи и отвержения

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

депривация заботы: отсутствие тепла, внимания, дружеских отношений, любви;
депривация эмпатии: отсутствие понимания, самораскрытия, выслушивания или разделения чувств с другими;

депривация защиты: отсутствие поддержки и руководства со стороны окружающих.

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

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

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

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

2.Домен нарушенной автономии

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

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

Медицинские катастрофы: например, сердечные приступы, СПИД;
Эмоциональные катастрофы: например, страх сойти с ума;
Внешние катастрофы: например, страх стать жертвой преступников, авиакатастрофы, землетрясения.

Чрезмерная эмоциональная привязанность и близость к одному или нескольким значимым другим (часто родителям) приводит к нарушению формирования собственной идентичности. Такие люди часто испытывают чувство пустоты и спутанности, не имея никакого направления, или в крайних случаях ставят под сомнение свое существование.

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

3.Домен нарушенных границ

Человек верит, что он превосходит других людей, имеет право на особые привилегии; или не считает себя связанным правилами взаимности, которые определяют нормальное социальное взаимодействие. Часто настаивает на том, что имеет право делать или иметь все что угодно, независимо от реалистичности своих планов и мнения других людей об этом.
Испытывает желание чувствовать превосходство над другими (например, быть одним из самых успешных, известных, богатых), стремиться к достижению власти или контроля, а не одобрения и внимания. Человек стремится к доминированию над другими: утверждению своей власти, принуждению к своей точке зрения или контролю за поведением других в соответствии с собственными желаниями, без сочувствия или заботы о нуждах и чувствах других.

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

4.Домен направленности на других

Человек старается угодить другим, чтобы получить одобрение, понравиться окружающим и избежать конфликтов или агрессии. Существует в двух формах:

Подавление своих желаний и потребностей;
Подавление чувств и эмоций.

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

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

5.Домен сверхбдительности и подавления эмоций

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

Человек считает, что необходимо подавлять свои спонтанные желания и проявления, эмоции, чувства, опасаясь, что проявление эмоций приведёт к потере самоуважения, изоляции, нападению или может навредить людям. Такие люди запрещают себе не только гнев и агрессию, но и позитивные эмоции, испытывают сложности в предъявлении своей уязвимости, им трудно говорить о чувствах, они часто излишне следуют ритуалам и правилам этикета.

Человек прилагает огромные усилия, чтобы добиться соответствия внутренним жестким стандартам даже ценой здоровья и/или личного счастья. Стандарты могут касаться статуса, внешности, финансового положения и т. д. При этом человек испытывает постоянное напряжение от давления как внешних обстоятельств, которые часто сам создаёт, так и от внутреннего давления чувства долга или гиперответственности.

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

ПОЗИТИВНЫЕ СХЕМЫ

14 позитивных схем, описанные John Philip Louis

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

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

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

Базовое ощущение, что всё в порядке, ничего не грозит, никакой катастрофы не случится. Человек чувствует себя в безопасности в толпе, вне дома. Он уверен в своей финансовой стабильности и не боится остаться без средств к существованию в будущем. Старается сохранять здоровый образ жизни, но ощущает себя физически здоровым и не задумывается о тяжелых заболеваниях, пока врачи не поставят диагноз. Принимает решения без страха за возможные катастрофические последствия ошибок. Способен оптимистично радоваться тому хорошему, что происходит в жизни, не задумываясь о возможных невзгодах.

Способность свободно выражать и обсуждать возникающие эмоции; где уместно — отвечать и вести себя спонтанно, не подавляя свои чувства. Человеку комфортно демонстрировать свою симпатию и привязанность к приятным ему людям.

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

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

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

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

Человек здраво оценивает свои способности, ему не нужно непременно быть среди лучших для того, чтобы быть довольным собой. В его жизни есть разумное место для отдыха, расслабления и удовольствий, даже если пока сделано не всё, что необходимо. Необязательно стремиться к совершенству, можно просто быть «достаточно хорошим». Можно позволять чему-то идти так, как оно идет, не чувствуя за это чрезмерной ответственности — особенно в отношении того, что затруднительно контролировать.

Человек чувствует, что имеет значение для других, даже если не находится в центре их внимания. Его самооценка и оценка ситуации опирается на его собственные взгляды и мало зависит от мнения других. Он не нуждается в похвалах и комплиментах или в подтверждении своего статуса (карьерного, финансового и т. д.), чтобы считать себя значимым и достойным; испытывает удовлетворение от результатов своей деятельности, вне зависимости от того, были ли они видны кому-то ещё.

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

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

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

Схемы — это глубинные убеждения человека, и они проявляются в поведении, эмоциях, мыслях, на языке схема-терапии в «режимах»…

Режимы?! О, а что это?

Режимы бывают детскими, критикующими, копинговыми и здоровыми! Обо всех режимах мы рассказываем на семинарах и воркшопах, там вы научитесь их распознавать!

Схемы — это глубинные убеждения человека, и они проявляются в поведении, эмоциях, мыслях, на языке схема-терапии в «режимах»

Режимы?! О, а что это?

Режимы?!
О, а что это?

Режимы бывают детскими, критикующими, копинговыми и здоровыми! Мы рассказываем о них на наших воркшопах, там вы научитесь их распознавать!

УЗНАТЬ БОЛЬШЕ О ВОРКШОПЕ

ЧИТАТЬ О РЕЖИМАХ

5 «Пример и схема ответа (Описание API)»

Edit me

Шаг 1. Описание ресурса

Шаг 2. Конечные точки и методы

Шаг 3. Параметры

Шаг 4. Пример запроса

Шаг 5. Пример и схема ответа

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

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

Примеры и схемы ответов

Ниже приведен пример ответа от SendGrid API. Их документация обеспечивает отображение Примера на одной вкладке:

А схема ответа на другой вкладке:

Определение ответа называется схемой или моделью (термины используются как синонимы) и равняется на язык и описания схемы JSON. Что особенно хорошо в примере SendGrid, так это использование тегов раскрытия / свертывания для отражения той же структуры, что и в примере, с объектами на разных уровнях.

Swagger UI также предоставляет и пример значения и схему/модель. Например, в примере документа API Sunrise и Sunset Times, который используется в практике SwaggerUI (которое будет приведено позже в курсе), можно увидеть различие между примером ответа и схемой ответа. Вот

Пример значения:

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

Схема ответа содержит все возможные свойства, возвращаемые в ответе. Вот почему нужен и пример ответа, и схема ответа. Вот схема ответа для API Sunrise и Sunset Times:

Схема или модель обеспечивает следующее:

Описание каждого свойства;
Определение типа данных для каждого свойства;
Является ли каждое свойство обязательным или необязательным.

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

Нужно ли определять ответ?

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

Большая часть документации была бы лучше с подробно описанным ответом, особенно если свойства являются сокращенными или загадочными. Разработчики иногда сокращают ответы, чтобы повысить производительность за счет уменьшения объема отправляемого текста. В одной конечной точке, ответ содержал около 20 различных аббревиатур из двух букв. Чтобы выяснить, что означает каждая аббревиатура, было потрачено несколько дней и обнаружено, что многие разработчики, работавшие над этим API, даже не знали, что означают многие ответы.

Использование реалистичных значений в примере ответа

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

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

Форматируем JSON и используем подсветку синтаксиса кода

Используйте правильный формат JSON для ответа. Такие инструменты, как JSON Formatter and Validator, помогут скорректировать синтаксис.

Если есть возможность добавить подсветку синтаксиса, обязательно нужно делать это. При использовании статического генератора сайтов, например Jekyll или синтаксис Markdown с GitHub, можно использовать встроенную подсветку синтаксиса Rouge. Другие статические генераторы сайтов могут использовать Pygments или аналогичные расширения.

Rouge и Pygments полагаются на «лексеры», чтобы указать, как код должен быть выделен. Например, некоторыми распространенными лексерами являются java, json, html, xml, cpp, dotnet и javascript.

Стратегии документирования вложенных объектов

Часто бывает, ответ содержит вложенные объекты (объекты внутри объектов) или повторяющиеся элементы. Форматирование документации для схемы ответа является одним из наиболее сложных аспектов справочной документации API.

Очень популярно использование таблиц. В курсе Петера Грюнбаума по технической документацииAPI для Udemy Грюнбаум представляет вложенные объекты, используя таблицы с различными столбцами:

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

Dropbox API представляет вложение косой чертой. Например, name_details/, team/ и quota_info указывают несколько уровней объекта.

Другие API будут вкладывать определения ответов для имитации структуры JSON. Вот пример из bit.ly API:

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

Подход eBay еще уникальнее. В их случае MinimumAdvertisedPrice вложен в DiscountPriceInfo, который вложен в Item, который вложен в ItemArray. (Обратите внимание, что этот ответ находится в формате XML вместо JSON.):

Вот документация ответа:

Также интересно, сколько деталей eBay включает для каждого элемента. В то время как авторы Twitter, опускают описания, авторы eBay пишут небольшие романы, описывающие каждый элемент в ответе.

Дизайн в три колонки

Некоторые API-интерфейсы помещают ответ в правый столбец, чтобы вы могли видеть его, одновременно просматривая описание и параметры ресурса. API Stripe сделал этот дизайн в три колонки популярным:

В дизайне Stripe образец ответа сопоставляется в правой части окна со схемой ответа в главном окне. Идея в том, что вы можете видеть и то и то одновременно. Описание не всегда совпадает с ответом, что может привести к путанице. Тем не менее, разделение примера ответа от схемы ответа в отдельных столбцах помогает различать их.

Многие API смоделировали свой дизайн после Stripe. Например, Slate, Spectacle или Readme.io. Следует ли использовать Дизайн в три колонки с документацией по API? Может быть.

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

MYOB Developer Center использует интересный подход к документированию JSON в своих API. Они перечисляют структуру JSON в виде таблицы, с разными уровнями отступов. Можно навести курсор мыши на поле с для появления всплывающей подсказки с описанием или щелкнуть по полю, чтобы раскрыть описание ниже. Использование всплывающих подсказок позволяет идеально выровнять строки, содержащие пример и описание.

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

Встраивание динамических ответов

Иногда ответы генерируются динамически на основе вызовов API в тестовой системе. Например, посмотрите на API Rhapsody и щелкните конечную точку — ответ генерируется динамически.

Другой API с динамическими ответами — это API OpenWeatherMap (с которым мы практиковались ранее). Если щелкнуть ссылку в разделе «Примеры вызовов API», например http://samples.openweathermap.org/data/2.5/weather?q=London, вы увидите ответ, возвращенный в браузере.

На самом деле, ответ OpenWeatherMap не генерируется динамически, но он так выглядит.

API Citygrid, который мы рассмотрели в разделе Пример запроса, также динамически генерирует ответы.

Такой динамический подход хорошо подходит для запросов GET, которые возвращают публичную информацию. Однако, вероятно, он не будет масштабироваться для других методов (таких как POST или DELETE) или для запроса авторизации.

Что насчет кодов ошибок?

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

Пример и схема ответа конечной точки SurfReport

Давайте создадим раздел для нашей конечной точки surfreport/{beachId} , в котором покажем пример и схему ответа.

Вот пример к разделу:

Пример ответа

Ниже пример ответа конечной точки surfreport/{beachId}

{
    "surfreport": [
        {
            "beach": "Santa Cruz",
            "monday": {
                "1pm": {
                    "tide": 5,
                    "wind": 15,
                    "watertemp": 80,
                    "surfheight": 5,
                    "recommendation": "Go surfing!"
                },
                "2pm": {
                    "tide": -1,
                    "wind": 1,
                    "watertemp": 50,
                    "surfheight": 3,
                    "recommendation": "Surfing conditions are okay, not great."
                },
                "3pm": {
                    "tide": -1,
                    "wind": 10,
                    "watertemp": 65,
                    "surfheight": 1,
                    "recommendation": "Not a good day for surfing.
 "
                }
                ...
            }
        }
    ]
}

В таблице ниже описание для каждого пункта

Пункт ответа	Описание	Тип данных
beach	Пляж, выбранный на основе идентификатора пляжа в запросе. Название пляжа — это официальное название, описанное в базе геоданных Службы национальных парков.	string
{day}	Выбранный день недели. В ответ возвращается максимум 3 дня.	Object
{time}	Выбранное время для погодный условий. Этот элемент включается только в том случае, если в запрос включен параметр времени.	string
{day}/{time}/tide	Уровень прилива на пляже в определенный день и время. Прилив — это расстояние внутри страны, до которого поднимается вода, и может быть положительным или отрицательным числом. При отливе, число отрицательное. При приливе, число положительное. Точка 0 отражает линию, при отсутствии прилива/отлива, и находится в переходе между двумя состояниями.	Integer
{day}/{time}/wind	Скорость ветра на пляже измеряется в узлах (морских миль в час). Ветер влияет на высоту прибоя и общие условия волнения. Скорость ветра более 15 узлов делает условия серфинга нежелательными, потому что ветер создает белые шапки и неспокойную воду.	Integer
{day}/{time}/watertemp	Температура воды, возвращаемая в градусах Фаренгейта или Цельсия, в зависимости от указанных единиц измерения. Для температуры воды ниже 70 F может потребоваться гидрокостюм. При температуре ниже 60, вам понадобится как минимум 3-миллиметровый гидрокостюм и желательно пинетки, чтобы согреться.	Integer
{day}/{time}/surfheight	Высота волн возвращается в футах или сантиметрах в, зависимости от указанных единиц измерения. Высота прибоя 3 фута — минимальный размер, необходимый для серфинга. Если высота прибоя превышает 10 футов, заниматься серфингом небезопасно.	Integer
{day}/{time}/recommendation	Общая рекомендация, основанная на сочетании различных факторов (ветер, температура воды, высота полета). Возможны три варианта ответа: (1) «Займитесь серфингом!», (2) «Условия серфинга в порядке, но не круто», и (3) «Не очень хороший день для серфинга». Каждый из трех факторов оценивается максимум в 33,33 балла, в зависимости от идеала для каждого элемента. Три элемента объединены, чтобы сформировать процент. От 0% до 59% дает ответ 3, от 60% до 80% дает ответ 2, а от 81% до 100% дает ответ 1.	String

Следующие шаги

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

🔙

Go next ➡

Схема описания соединителя поиска — Win32 apps

Twitter LinkedIn Facebook Адрес электронной почты

Статья
09/22/2022
Чтение занимает 3 мин

Содержит схему описания соединителя поиска, используемую библиотеками обозревателя Windows и федеративными поставщиками поиска. Схема указывает структуру и требования для файлов описания соединителя поиска (*.searchConnector-ms) и элементов searchConnectorDescriptionType файлов описания библиотеки оболочки (*.library-ms).

В этом разделе описывается схема, связанная с соединителями федеративного поиска. Дополнительные сведения о библиотеках и схеме описания библиотек см. в разделе «Схема описания библиотеки».

Этот раздел включает следующие подразделы:

Что такое соединители поиска?
Как работают файлы описания соединителя поиска?
Что такое схема описания соединителя поиска?
Каковы основные части схемы?
Примеры файлов описания соединителя поиска

Дополнительные ресурсы
Связанные разделы

Что такое соединители поиска?

Соединители поиска подключают пользователей к данным, хранящимся в веб-службах или удаленных расположениях хранилища. С помощью Windows 7 пользователи могут устанавливать соединители поиска для таких расположений, как веб-службы, чтобы они искали эти расположения непосредственно из обозревателя Windows. Соединители поиска — это файлы описания соединителя поиска (*.searchConnector-ms), которые указывают, как подключаться, отправлять запросы и получать результаты из расположения.

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

Как работают файлы описания соединителя поиска?

Когда файлы описания соединителя поиска устанавливаются в системах пользователей, пользователи могут открыть Windows Explorer, щелкнуть соединитель поиска в области навигации и ввести поисковый запрос. Windows Explorer отправляет запрос с помощью сведений из файла описания соединителя поиска, например поставщика для использования и области поиска. Результаты возвращаются как элементы RSS или Atom и отображаются пользователям, как если бы они были обычными элементами оболочки.

Развертывание файла описания соединителя поиска зависит от типа расположения, который поддерживает соединитель поиска:

В файле конфигурации OpenSearch (*.osdx) для веб-службы
В рамках установки обработчика протокола

При открытии OSDX-файла или установке обработчика протокола необходимо убедиться в следующем:

Файл .searchconnector-ms создается в папке
поиска пользователей Windows (%userprofile%/Search).
Ярлык файла .searchconnector-ms создается в папке ссылок пользователей (%userprofile%/Links).

Что такое схема описания соединителя поиска?

Схема описания соединителя поиска — это xml-схема, которая определяет структуру файлов описания соединителя поиска (*.searchConnector-ms). Каждый соединитель поиска должен иметь файл описания соединителя поиска, который указывает, как подключаться, отправлять запросы и получать результаты из расположения.

Каковы основные части схемы?

В следующей таблице перечислены основные части схемы.

Дочерние элементы	Описание
isSearchOnlyItem	Определяет, являются ли расположения, поддерживаемые соединителем поиска, доступны только для поиска или поиска и просмотра.
isDefaultSaveLocation	Только для использования библиотеки.
isDefaultNonOwnerSaveLocation	Только для использования библиотеки.
description	Описывает соединитель поиска.
iconReference	Определяет расположение настраиваемого значка для соединителя поиска.
imageLink	Определяет расположение пользовательского эскиза для соединителя поиска.
author	Определяет автора соединителя поиска.
Datecreated	Определяет дату создания соединителя поиска.
templateInfo	Указывает тип папки для соединителя поиска.
locationProvider	Указывает поставщик поиска, используемый этим соединителем поиска.
область	Указывает расположения для включения и исключения из области поиска.
propertyStore	Указывает расположение объекта IPropertyStore на основе XML для этого соединителя поиска. IPropertyStore поддерживает открытые метаданные соединителя поиска.
includeInStartMenuScope	Указывает, следует ли включать расположение, представленное соединителем поиска, в область поиска меню .
Домена	Определяет домен верхнего уровня соединителя поиска.
supportsAdvancedQuerySyntax	Указывает, поддерживает ли соединитель поиска расширенный синтаксис запросов (AQS).
isIndexed	Указывает, индексируется ли расположение, представленное соединителем поиска.

Примеры файлов описания соединителя поиска

Ниже приведен пример файла описания соединителя поиска для федеративной веб-службы поиска.

<?xml version="1.0" encoding="UTF-8"?>
<searchConnectorDescription xmlns="http://schemas.microsoft.com/windows/2009/searchConnector">
  <description>Search MSDN. Powered by live.com</description>
  <isSearchOnlyItem>true</isSearchOnlyItem>
  <domain>https://social.msdn.microsoft.com</domain>
  <supportsAdvancedQuerySyntax>false</supportsAdvancedQuerySyntax>
  <templateInfo>
    <folderType>{8FAF9629-1980-46FF-8023-9DCEAB9C3EE3}</folderType>
  </templateInfo>
  <propertyStore>
    <property name="OpenSearchHTMLRolloverTemplate">https://social.msdn.microsoft.com/Search/?Query={searchTerms}</property>
  </propertyStore>
  <locationProvider clsid="{48E277F6-4E74-4cd6-BA6F-FA4F42898223}">
    <propertyBag>
      <property name="OpenSearchShortName">MSDN</property>
      <property name="OpenSearchQueryTemplate">https://social.msdn.microsoft.com/Search/Feed. aspx?locale=en-US&Query={searchTerms}&format=RSS&StartIndex={startIndex}</property>
      <property name="MaximumResultCount" type="uint32">100</property>
    </propertyBag>
  </locationProvider>
</searchConnectorDescription>

Ниже приведен пример файла описания соединителя поиска для обработчика протокола MAPI.

<?xml version="1.0" encoding="UTF-8"?>
<searchConnectorDescription xmlns="http://schemas.microsoft.com/windows/2009/searchConnector">
    <description>Microsoft Outlook</description>
    <isSearchOnlyItem>true</isSearchOnlyItem>
    <includeInStartMenuScope>true</includeInStartMenuScope>
    <templateInfo>
        <folderType>{91475FE5-586B-4EBA-8D75-D17434B8CDF6}</folderType>
    </templateInfo>
    <simpleLocation>
        <url>mapi://{S-1-5-21-2127521184-1604012920-1887927527-2779359}/</url>
    </simpleLocation>
</searchConnectorDescription>

Дополнительные ресурсы

Дополнительные сведения о схеме описания библиотеки см. в разделе «Схема описания библиотеки».
Дополнительные сведения об установке соединителя поиска см. в статье «Федеративный поиск» в Windows.

Reference
Элемент searchConnectorDescriptionType (схема соединителя поиска)
Другие ресурсы
OpenSearch
Центре загрузки Майкрософт

Список дезадаптивных схем в схема-терапии и краткое описание схем

Янг и соавторы определили 18 дисфункциональных схем, которые объединяются в пять групп «сфер».

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

Потеря связи и отвержение:

Эта сфера схем характеризуется трудностями привязанности. Все схемы этой группы должным образом связаны с отсутствием безопасности и надежности в межличностных отношениях.

Покинутость / нестабильности отношений

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

Недоверия / ожидания жестокого обращения

Выражается в ожидании ущемления, унижения, манипуляций или плохого отношения со стороны других лиц. Когда люди относятся к ним с теплотой, они часто думают, что те имеют скрытые мотивы.

Эмоциональной депривации

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

Дефективности / стыда

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

Социальной изоляции

Люди в этой схеме чувствуют себя «оторванными», «отчужденными» от других и не имеют чувство принадлежности к какой-либо группе. Будто они отличаются от всех остальных.

Ограниченная автономия:

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

Зависимости / беспомощности

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

Уязвимости

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

Слияния / неразвитой идентичности

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

Неуспешности/ неизбежных неудач

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

Схемы из сферы нарушения границ:

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

Особого статуса и прав / грандиозности

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

Недостаточного самоконтроля / самодисциплины

Недостаточного самоконтроля / самодисциплины
Люди с этой схемой обычно испытывают трудности с самоконтролем и способностью отсрочить вознаграждение. Они часто не доводят до конца «скучные дела», а также нетерпеливо относятся к задачам, которые требуют дисциплины и настойчивости.

Схемы направленные на других:

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

Покорности

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

Самопожертвования

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

Поиска одобрения

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

Чрезмерной бдительности и запрета:

Люди с этими схемами избегают переживаний, а так же выражения спонтанных эмоций и потребностей.

Негативизма / пессимизма

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

Подавления эмоций

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

Сверхвысоких стандартов / придирчивость

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

Наказания / пунитивности

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

За материалами А. Арнц и Г. Якоб

Схема кинематики токарного станка

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

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

Строение токарно-винторезного станка

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

Рис.: 1 – передняя бабка с коробкой скоростей, 2 – гитара сменных колес, 3 – коробка подач, 4 – станина, 5 – фартук, 6 – суппорт, 7 – задняя бабка, 8 – шкаф с электрооборудованием.

Как и у большинства промышленного оборудования, основой этого станка выступает станина. Она выполняется литьем или сваркой и обязательно крепится к полу анкерными болтами. С левой стороны относительно рабочего на станине располагается передняя или шпиндельная бабка. Она представляет собой пустотелый корпус, в котором находятся, шестерни, шпиндель, подшипники, система смазки и переключения диапазонов. На передней панели бабки находятся многочисленные элементы управления станком. Шпиндель выходит из передней бабки в рабочую зону. На шпиндель устанавливаются приспособления для удержания заготовки, основная часть которых — патроны с разным количеством кулачков.

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

Суппорт является элементом станка, на котором устанавливается основной инструмент. Нижние салазки суппорта перемещаются по продольным направляющим, расположенным на станине. Сверху находятся верхние салазки, они расположены перпендикулярно к нижним. Перемещающаяся по ним резцовая каретка имеет возможность повтора в горизонтальной плоскости. На ней находится резцедержатель, в котором закрепляется инструмент. Таким образом, конструкция суппорта и направляющих станины обеспечивает инструменту возможность продольного и поперечного движения, а также наклона относительно центра. Это позволяет обрабатывать инструментом цилиндрические и конические поверхности.

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

Кинематическая схема токарно-винторезного станка

Главное движение станка осуществляется односкоростным асинхронным трехфазным двигателем, в редких случаях многоскоростным.

Движение с двигателя передается на коробку скоростей посредством клиноременной передачи. В коробке скоростей находится 6-8 валов с зубчатыми колесами. Валы для удобства нумеруются римскими цифрами, первым идет вал со шкивом, далее по кинематике. Выбирая используемые передачи, можно регулировать скорость вращения шпинделя в широких пределах. На токарных станках можно получить более 20 различных скоростей вращения шпинделя с закрепленной на ней заготовкой. Для обратного вращения шпинделя предусмотрены две фрикционные муфты.

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

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

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

Предыдущая статья

Следующая статья

Получить консультацию

по инструменту, методам обработки, режимам или подобрать необходимое оборудование можно связавшись с нашими менеджерами или отделом САПР

Также Вы можете подобрать и приобрести режущий инструмент и оснастку к станку, производства Тайваня, Израиля

Отправляя заявку, вы соглашаетесь с политикой конфиденциальности

Проработать технологию, подобрать станок и инструмент

Схема Определение и значение | Dictionary.

com

Основные определения
Синонимы
Тест
Связанный контент
Примеры
Британский
Идиомы и фразы оцениваются на основе уровня сложности

[ ским ]

/ ским /

Сохрани это слово!

См. синонимы для: схема / схема / схемы / схемы на Thesaurus.com

Показывает уровень оценки в зависимости от сложности слова.

сущ.

план, замысел или программа действий, которым необходимо следовать; проект.

закулисный участок; интрига.

дальновидный или непрактичный проект.

совокупность или система родственных доктрин, теорий и т. д.: схема философии.

любая система взаимосвязанных вещей, частей и т. д. или способ ее расположения.

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

аналитическая или табличная выписка.

диаграмма, карта и т.п.

астрологическая диаграмма небес.

глагол (используется с дополнением), замышлял, замышлял.

разработать в виде схемы; заговор; участок; изобретать.

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

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

ДРУГИЕ СЛОВА ДЛЯ схемы

2 уловка, клика, заговор.

5 выкройка, схема.

См. синонимы к слову схема на Thesaurus.com

ВИКТОРИНА

Сыграем ли мы в «ДОЛЖЕН» ПРОТИВ. «ДОЛЖЕН» ВЫЗОВ?

Должны ли вы пройти этот тест на «должен» или «должен»? Это должно оказаться быстрым вызовом!

Вопрос 1 из 6

Какая форма используется для указания обязательства или обязанности кого-либо?

Происхождение схемы

Впервые записано в 1545–1555 гг. ; от средневекового латинского schēma (основа schēmat-), от греческого schêma «форма, фигура»

синоним этюд схемы

1, 6. См. план. 10. См. сюжет.

ДРУГИЕ СЛОВА ИЗ схемы

схема·менее, прилагательноеschem·er, существительноеout·схема, глагол (используется с дополнением), out·schemed, out·schem·ing.sub·scheme, существительное

under·scheme, существительное·schemed, прилагательное

Слова поблизости схема

Schelling, schema, схематический, схематизм, схематизировать, схема, схема, схема, интрига, Скенектади, Шенгенская конвенция

Dictionary.com Unabridged Основано на словаре Random House Unabridged Dictionary, © Random House, Inc., 2022 г.

Слова, связанные со схемой

расположение, схема, дизайн, устройство, план игры, шаблон, план, программа, проект, предложение, стратегия, система, теория, действие, заговор, уловка, практика, сценарий, схема, кодификация

Как использовать схему в предложении

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

Как математический фокус-покус спас физику элементарных частиц|Чарли Вуд|17 сентября 2020 г.|Журнал Quanta
В Великобритании, как и в ряде других стран, развернута схема сохранения рабочих мест, которая обеспечивает аналогичную поддержку.

Рынки труда в США и Европе на удивление похожи|Дэн Копф|16 сентября 2020 г.|Quartz
Для участия в схеме пользователям необходимо приобрести или уже иметь Apple Watch.

Одна страна теперь платит гражданам за занятия спортом с помощью Apple Watch|Наоми Сюй Элегантная|16 сентября 2020 г.|Fortune
Многие жители округа Сан-Диего платят одни из самых высоких тарифов на воду в стране, но благодаря государственному надзорному органу жители Империал-Бич и Коронадо не будут подвергаться подозрительной схеме ценообразования на воду.

Утренний отчет: Сан-Диего игнорирует неиспользованный источник воды|Голос Сан-Диего|15 сентября 2020 г.|Голос Сан-Диего

В отличие от выборов, Лам говорит, что программа всеобщего тестирования не проводится в один день.

Общегородское тестирование на COVID-19 в Гонконге стало барометром общественного доверия|eamonbarrett|9 сентября 2020 г.|Fortune
Фтор впервые попал в американское водоснабжение через довольно неэлегантную технократическую схему.

Противники фтора — антипрививочники|Майкл Шульсон|27 июля 2016|DAILY BEAST
В этой дурацкой схеме разбогатеть, будут ли они все приносить извинения, если он выпишет чек?

Филисия Рашад и культ Косби Трутерс|Стерео Уильямс|8 января 2015 г.|DAILY BEAST
Эта схема была осуждена группами по защите гражданских свобод и расследована Национальной ассоциацией директоров школ.

Великобритания может шпионить за дошкольниками, ищущими потенциальных джихадистов|Нико Хайнс|7 января 2015|DAILY BEAST
Южнокорейская полиция раскрыла одну такую схему в 2011 году, которая, как говорят, принесла миллионы.

Внутри «удивительно великого» северокорейского хакерского отеля|Майкл Дейли|20 декабря 2014 г. |DAILY BEAST
Ритейлеры пострадали от этой схемы, потому что сдержек и противовесов было мало в 2012 году, когда мошенничество на eBay достигло своего пика.

Безумная афера на 11 миллиардов долларов в пунктах возврата розничных продавцов|M.L. Nestel|19 декабря 2014|DAILY BEAST
Видеть, как часть моей схемы, от которой я так надеялся, разваливается на глазах – это сводит с ума!

Дневник Галлиполи, Том I|Иан Гамильтон
Герцог без труда пробудил в голове юной Лоррейн желания, необходимые для его замысла.

The Pastor’s Fire-side Vol. 3 из 4|Джейн Портер
Но я чувствую оптимизм в мужском духе; сангвиник в моем собственном духе; сангвиник в обоснованности моей схемы.

Дневник Галлиполи, Том I|Иан Гамильтон
Даже если эта цветовая схема не сработает, для аскифской фразы все же есть оправдание.

Панч, или Лондонский Шаривари, том 107, 3 ноября 1894 г. | Разное
Операции по схеме начались в августе 1878 г. , когда были снесены дома на Нью-стрит.

Showell’s Dictionary of Birmingham|Thomas T. Harman and Walter Showell

British Dictionary definitions for scheme

scheme

/ (skiːm) /

noun

a systematic plan for a course of action

a систематическое расположение взаимосвязанных частей; система

тайный заговор

дальновидный или неосуществимый проект

карта, диаграмма или план

астрологическая диаграмма, показывающая аспекты небесных тел в определенное время

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

глагол

(tr) разработать систему для

интриговать (для) тайным образом

Производные формы схемы

интриган, существительное

Слово Происхождение схемы

16:0018 Латинская схема 16:0018 Cchema , от греческого skēma форма

Collins English Dictionary — Полное и полное цифровое издание 2012 г. © William Collins Sons & Co. Ltd., 1979, 1986 © HarperCollins Publishers 1998, 2000, 2003, 2005, 2006, 2007, 2009, 2012

Другие идиомы и фразы со схемой

схема

см. лучшие планы (схемы).

Словарь идиом американского наследия® Авторские права © 2002, 2001, 1995, издательство Houghton Mifflin Harcourt Publishing Company. Опубликовано издательством Houghton Mifflin Harcourt Publishing Company.

Определение схемы и значение | Английский словарь Коллинза

Видео: произношение

схема

Вам также может понравиться

Цитаты

Лучшие планы мышей и людей

схема

Тенденции

схема

На других языках

схема

Британский английский: схема /skiːm/ СУЩЕСТВИТЕЛЬНОЕ

Схема — это план или договоренность, особенно разработанная правительством или другой организацией.

…схемы помощи в борьбе с безработицей.

Американский английский: программа /ˈproʊgræm, -grəm/ plan
Арабский: خِطَّة
Бразильский португальский: esquema
Китайский: 计划
Хорватский: shema
Чехия: система
Датский: план программа
Голландский: программа
Европейский испанский: план
Финский: suunnitelma
Французский: план politique
Немецкий: План
Греческий: σχέδιο
Итальянский: фортепиано
Японский: 計画
Корейский: 계획
Норвежский: план обработки
польский: план проект
Европейский португальский: esquema
Румынский: схема
Русский: схема
Испанский: план
Шведский: план метод
Тайский: แผนการ
Турецкий: план
Украинский: схема
Вьетнамский: kế hoạch

Британский английский: схема СУЩЕСТВИТЕЛЬНОЕ /skiːm/

Схема — это чей-то план достижения чего-то, особенно того, что принесет им некоторую пользу.

…схема быстрого заработка, чтобы пережить лето.

Американский английский: схема /ˈским/
Бразильский португальский: esquema
Китайский: 计划
Европейский Испанский: план
Французский: план
Немецкий: план
Итальянский: фортепиано
Японский: 計画
Корейский: 계획
Европейский португальский: esquema
Испанский: план

Британский английский: схема ГЛАГОЛ /skiːm/

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

Все всегда плетут интриги и интриги.

Американский английский: схема /ˈskim/
Бразильский португальский: fazer esquema
Китайский: 计划
Европейский Испанский: maquinar
Французский: менеджер
Немецкий: интрига
Итальянский: complottare
Японский: 策略を立てる
Корейский: 책략을 꾸미다
Европейский португальский: fazer esquema
Испанский: maquinar
Тайский: วางแผนลับ

Связанные условия

схема

Новинка от Коллинза

Быстрое задание

Обзор викторины

Вопрос: 1

—

Оценка: 0 / 5

маленький

большой

обвести кого-нибудь вокруг пальца

нос

волосы

поднять чью-нибудь

голову

шею

смейся

Ваш счет:

26 сентября 2022 г.

Слово дня

полиглот

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

Подпишитесь на нашу рассылку

Получайте последние новости и получайте доступ к эксклюзивным обновлениям и предложениям

Зарегистрируйтесь

Неделя кодирования: 9 ключевых терминов для вашего технологического глоссария

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

Учебные пособия для каждого этапа вашего обучения

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

В чем разница между объявлением и рекламой?

На этой неделе мы рассмотрим два слова, которые иногда путают: объявление и реклама. Улучшите свой английский с Collins. Подробнее

Collins English Dictionary Apps

Загрузите наши приложения English Dictionary, доступные как для iOS, так и для Android. Подробнее

Словари Collins для школ

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

Списки слов

У нас есть почти 200 списков слов из самых разных тем, таких как виды бабочек, куртки, валюты, овощи и узлы! Удивите своих друзей своими новыми знаниями! Подробнее

Обновление нашего использования

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

Зона 51, Звездолёт и Урожайная Луна: слова сентября в новостях

Уверен, многие согласятся, что мы живем в странные времена. Но должны ли они быть настолько странными, чтобы Зона 51 попала в заголовки газет? А при чем здесь рыбы, похожие на инопланетян. Сентябрьские слова в новостях объясняют все. Подробнее

Оценка Scrabble
за «схему»:
13

Быстрое задание

Обзор викторины

Вопрос: 1

—

Оценка: 0 / 5

ездил верхом

У меня никогда не было лошади.

сдержанный

скрытый

Я не хочу, чтобы кто-нибудь знал об этом, поэтому будьте .

однотонный

плоский

Ковер зрительно увеличивает комнату.

Ваш счет:

Создайте учетную запись и войдите, чтобы получить доступ к этому БЕСПЛАТНОМУ контенту

Зарегистрируйтесь сейчас или войдите, чтобы получить доступ

SKOS Simple Knowledge Organization System Namespace Document

skos:altLabel
URI:	`http://www. w3.org/2004/02/skos/core#altLabel`
Определение:	Раздел 5. Лексические метки
Этикетка:	альтернативная этикетка
Суперсвойства:	`http://www.w3.org/2000/01/rdf-schema#label`
скос: широкое совпадение
URI:	`http://www.w3.org/2004/02/skos/core#broadMatch`
Определение:	Раздел 10. Свойства сопоставления
Этикетка:	имеет более широкое соответствие
Суперсвойства:	`skos:broader` `skos:mappingRelation`
Инверсия:	`skos:narrowMatch`
скос:шире
URI:	`http://www. w3.org/2004/02/skos/core#broader`
Определение:	Раздел 8. Семантические отношения
Этикетка:	имеет более широкий
Суперсвойства:	`skos:broaderTransitive`
Инверсия:	`скошь:уже`
skos:broaderTransitive
URI:	`http://www.w3.org/2004/02/skos/core#broaderTransitive`
Определение:	Раздел 8. Семантические отношения
Этикетка:	имеет более широкий переходный
Суперсвойства:	`skos:semanticRelation`
Инверсия:	`skos:narrowerTransitive`
Другие характеристики:	Переходный
skos:changeNote
URI:	`http://www. w3.org/2004/02/skos/core#changeNote`
Определение:	Раздел 7. Свойства документации
Этикетка:	примечание об изменении
Суперсвойства:	`код: примечание`
скос:closeMatch
URI:	`http://www.w3.org/2004/02/skos/core#closeMatch`
Определение:	Раздел 10. Свойства сопоставления
Этикетка:	имеет близкое соответствие
Суперсвойства:	`skos:mappingRelation`
Другие характеристики:	Симметричный
скос: определение
URI:	`http://www.w3.org/2004/02/skos/core#definition`
Определение:	Раздел 7. Свойства документации
Этикетка:	определение
Суперсвойства:	`код: примечание`
skos: EditorialNote
URI:	`http://www.w3.org/2004/02/skos/core#editorialNote`
Определение:	Раздел 7. Свойства документации
Этикетка:	примечание редактора
Суперсвойства:	`код: примечание`
скос:exactMatch
URI:	`http://www.w3.org/2004/02/skos/core#exactMatch`
Определение:	Раздел 10. Свойства сопоставления
Этикетка:	имеет точное совпадение с
Суперсвойства:	`skos:closeMatch`
Другие характеристики:	Переходный Симметричный
скос:пример
URI:	`http://www. w3.org/2004/02/skos/core#example`
Определение:	Раздел 7. Свойства документации
Этикетка:	пример
Суперсвойства:	`код: примечание`
Скос: hasTopConcept
URI:	`http://www.w3.org/2004/02/skos/core#hasTopConcept`
Определение:	Раздел 4. Концептуальные схемы
Этикетка:	этикетка
Домен:	`skos:ConceptScheme`
Диапазон:	`skos:Concept`
Инверсия:	`skos:topConceptOf`
скос: скрытая метка
URI:	`http://www. w3.org/2004/02/skos/core#hiddenLabel`
Определение:	Раздел 5. Лексические метки
Этикетка:	скрытая этикетка
Суперсвойства:	`http://www.w3.org/2000/01/rdf-schema#label`
skos:historyNote
URI:	`http://www.w3.org/2004/02/skos/core#historyПримечание`
Определение:	Раздел 7. Свойства документации
Этикетка:	историческая справка
Суперсвойства:	`код: примечание`
схема: в схеме
URI:	`http://www.w3.org/2004/02/skos/core#inScheme`
Определение:	Раздел 4. Концептуальные схемы
Этикетка:	находится на схеме
Диапазон:	`skos:ConceptScheme`
skos:mappingRelation
URI:	`http://www.w3.org/2004/02/skos/core#mappingRelation`
Определение:	Раздел 10. Свойства сопоставления
Этикетка:	находится в сопоставлении с
Суперсвойства:	`skos:semanticRelation`
скос: член
URI:	`http://www.w3.org/2004/02/skos/core#member`
Определение:	Раздел 9. Коллекции понятий
Этикетка:	имеет член
Домен:	`skos:Коллекция`
Диапазон:	соединение скосов `:Концепция` и скосов `:Коллекция`
скос:memberList
URI:	`http://www. w3.org/2004/02/skos/core#memberList`
Определение:	Раздел 9. Коллекции понятий
Этикетка:	есть список участников
Домен:	`skos:OrderedCollection`
Диапазон:	`http://www.w3.org/1999/02/22-rdf-syntax-ns#List`
Другие характеристики:	Функциональный
skos:narrowMatch
URI:	`http://www.w3.org/2004/02/skos/core#narrowMatch`
Определение:	Раздел 10. Свойства сопоставления
Этикетка:	имеет более узкое соответствие
Суперсвойства:	`skos:mappingRelation` `skos:narrower`
Инверсия:	`skos:broadMatch`
скос:уже
URI:	`http://www. w3.org/2004/02/skos/core#narrower`
Определение:	Раздел 8. Семантические отношения
Этикетка:	уже
Суперсвойства:	`skos:narrowerTransitive`
Инверсия:	`skos:широкий`
skos:narrowerTransitive
URI:	`http://www.w3.org/2004/02/skos/core#narrowerTransitive`
Определение:	Раздел 8. Семантические отношения
Этикетка:	имеет более узкий переходный
Суперсвойства:	`skos:semanticRelation`
Инверсия:	`skos:broaderTransitive`
Другие характеристики:	Переходный
скос:обозначение
URI:	`http://www. w3.org/2004/02/skos/core#notation`
Определение:	Раздел 6. Обозначения
Этикетка:	обозначение
скос: примечание
URI:	`http://www.w3.org/2004/02/skos/core#note`
Определение:	Раздел 7. Свойства документации
Этикетка:	примечание
скос:prefLabel
URI:	`http://www.w3.org/2004/02/skos/core#prefLabel`
Определение:	Раздел 5. Лексические метки
Этикетка:	предпочтительная этикетка
Суперсвойства:	`http://www.w3.org/2000/01/rdf-schema#label`

URI:	`http://www. w3.org/2004/02/skos/core#related`
Определение:	Раздел 8. Семантические отношения
Этикетка:	связан
Суперсвойства:	`skos:semanticRelation`
Другие характеристики:	Симметричный

URI:	`http://www.w3.org/2004/02/skos/core#relatedMatch`
Определение:	Раздел 10. Свойства отображения
Этикетка:	имеет связанное совпадение
Суперсвойства:	`skos:mappingRelation` `skos:related`
Другие характеристики:	Симметричный
skos:scopeNote
URI:	`http://www. w3.org/2004/02/skos/core#scopeNote`
Определение:	Раздел 7. Свойства документации
Этикетка:	примечание по объему
Суперсвойства:	`код: примечание`
skos:semanticRelation
URI:	`http://www.w3.org/2004/02/skos/core#semanticRelation`
Определение:	Раздел 8. Семантические отношения
Этикетка:	находится в семантической связи с
Домен:	`skos:Concept`
Диапазон:	`skos:Concept`
skos:topConceptOf
URI:	`http://www.w3.org/2004/02/skos/core#topConceptOf`
Определение:	Раздел 4. Концептуальные схемы
Этикетка:	является верхним концептом схемы
Суперсвойства:	`схема: в схеме`
Инверсия:	`скос: hasTopConcept`

Что такое пирамидальная схема? Как это работает?

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

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

Эти операции, которые часто называют мошенничеством с пирамидами, являются незаконными в США.

Ключевые выводы

Пирамида направляет доходы от всех нанятых участников с более низких уровней организации к участникам с более высокими уровнями.
В США вербовка участников финансовых пирамид является уголовным преступлением.
Схемы пирамид основаны на доходах от сборов за трудоустройство, а не, как могут полагать участники, от продажи реальных товаров или услуг с реальной стоимостью.
Многоуровневые маркетинговые операции (MLM) — это законные бизнес-программы, в которых дистрибьюторы зарабатывают деньги от продажи материальных товаров и от комиссионных за покупки и продажи нанятых ими дистрибьюторов.
Схемы пирамид часто маскируются под MLM, но их внимание сосредоточено на вознаграждении от новобранцев, а не на доходах от продажи продукции.

Как работают финансовые пирамиды

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

Изображение Джули Бэнг © Investopedia 2019

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

Каждый из этих новых, 10 членов или участников платит Майку определенную плату за участие в возможности, которую он им предлагает. Затем каждому из этих членов предлагается набрать еще 10 членов, всего 100 членов.

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

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

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

Примечание

Согласно данным Комиссии по ценным бумагам и биржам США (SEC), инвесторы должны знать о следующих особенностях финансовых пирамид:

Отсутствие подлинного продукта или услуги
Обещания высокой прибыли в короткие сроки
Легкие деньги или пассивный доход
Отсутствие продемонстрированной выручки от розничных продаж
Требуется бай-ин
Сложная комиссионная структура
Акцент на вербовке

Типы пирамидальных схем

Многоуровневая маркетинговая пирамидальная схема

Многоуровневый маркетинг (MLM) — легальная бизнес-программа. Эта бизнес-модель предполагает продажу реальных товаров или услуг дистрибьюторами или участниками MLM. Дистрибьюторам платят за те продукты и услуги МЛМ, которые они продают. Они также могут получать доход от продаж, сделанных дистрибьюторами, которых они наняли, и от людей, которых эти новобранцы затем привлекли.

Однако некоторые финансовые пирамиды маскируются под МЛМ. Федеральная торговая комиссия предупреждает людей, чтобы они обращали внимание и избегали промоутеров MLM, которые:

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

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

Электронная почта цепочки

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

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

Схемы Понци

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

Схемы Понци обычно предполагают однократное первоначальное вложение только со стороны инвесторов. Затем эти инвесторы ждут обещанного возврата своих денег. Это обеспечивается новыми деньгами от других инвесторов, которых убедил принять участие лидер схемы. Большинство участников Понци в конечном итоге теряют все, когда деньги на такую схему иссякают.

Консультант по инвестициям Бернард Мэдофф, возможно, самый известный автор схемы Понци, был приговорен к 150 годам тюремного заключения за управление многомиллиардной схемой Понци. Мэдофф убедил многих высокопоставленных лиц инвестировать вместе с ним, фальсифицировал портфели и соответствующие документы и расплатился с ранними инвесторами деньгами, полученными от более поздних инвесторов. Большинство инвесторов потеряли все. Мэдофф умер в тюрьме 14 апреля 2021 года.

Пример схемы пирамиды

В последние годы Комиссия по ценным бумагам и биржам выдвинула обвинения, чтобы остановить пирамиду, маскирующуюся под программу MLM. Компания, которая называлась CKB, привлекала инвесторов по всему миру и, в частности, ориентировалась на азиатско-американские общины в Нью-Йорке и Калифорнии.

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

Как рушатся схемы пирамид

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

Схемы пирамид не могут функционировать в течение длительного времени. Люди всегда будут терять свои деньги. Даже ранние участники высокого уровня могут потерять деньги ближе к концу из-за периодов ожидания, которые задерживают платежи от новобранцев более низкого уровня.

Является ли пирамидальная схема незаконной в Соединенных Штатах?

По сути, да. В США вербовка любого человека для участия в финансовой пирамиде является уголовным преступлением. Это преступление может привести к четырем годам тюремного заключения и штрафу в размере 5000 долларов США.

Как успешны схемы пирамид?

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

Схемы пирамид — это то же самое, что и программы многоуровневого маркетинга?

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

Итог

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

Описание ансамбля метаморфических и внутренне неупорядоченных белков с высоким разрешением с использованием эффективной гибридной схемы параллельного темперирования

Abstract

Картирование ландшафтов свободной энергии сложных многоканальных метаморфических белков и слабонаправленных внутренне неупорядоченных белков (IDP) остается сложной задачей. В то время как моделирование молекулярной динамики выборки редких событий может быть полезным, оно часто требует либо наложения ограничений, либо повторного взвешивания сгенерированных данных, чтобы они соответствовали экспериментам. Здесь мы представляем метод параллельного темперирования, который использует ускоренную динамику воды и позволяет проводить эффективную и точную конформационную выборку самых разных белков. Мы демонстрируем повышенную эффективность выборки путем сравнения со стандартными модельными системами, такими как дипептид аланина, клетка TRP и β-шпилька. Метод успешно масштабируется для крупных метаморфических белков, таких как RFA-H, и для сильно неупорядоченных IDP, таких как гистатин-5. Для различных белков рассчитанные средние ансамблевые значения хорошо согласуются с ЯМР, SAXS и другими биофизическими экспериментами без необходимости повторного взвешивания. Обеспечивая точную выборку из разных ландшафтов, метод открывает двери для выборки ландшафта свободной энергии сложных неизведанных белков.

Введение

Биомолекулы не статичны, а демонстрируют зависящие от времени динамические движения, тесно связанные с их функциями. Молекулярное моделирование в настоящее время все чаще используется для визуализации подробных событий таких молекулярных движений с атомным разрешением, что часто невозможно с использованием экспериментальных методов. Тем не менее выборка при моделировании классической молекулярной динамики (МД) ограничена локальными минимумами ландшафта свободной энергии. Следовательно, доступ к сложным энергетическим ландшафтам белков далеко не тривиален для белков с многоэтапной укладкой 9.1823 1,2 , метаморфические белки ^3,4,5 и внутренне неупорядоченные белки (IDP) ^6,7,8 .

Усовершенствованное моделирование молекулярной динамики, такое как молекулярная динамика обмена температурными репликами (TREM) ⁹ , особенно полезно для выборки конформаций через энергетические барьеры и, следовательно, для ускорения наблюдений за редкими биомолекулярными переходами. В методе обмена репликами конформации отбираются с использованием нескольких реплик, смоделированных при серии низких и высоких температур, и стохастически заменяются через равные промежутки времени, чтобы получить несмещенный взвешенный по Больцману ансамбль конформаций. Однако количество реплик, необходимых для моделирования, экспоненциально растет со степенями свободы системы, что затрудняет ее применение в больших биомолекулярных растворах. Брюс Берн и его коллеги разработали мощную альтернативу, называемую обменом репликами с закалкой раствором (REST) 9.1823 10,11 , где они разработали гамильтониан для частичного нагрева подмножества системы (растворенного вещества). Подход сократил необходимое количество реплик в несколько раз. Было показано, что такой мощный дизайн гамильтониана имитирует слабое связывание пептида Aβ с липидным бислоем ¹² , латеральное уравновешивание липидов в бислое ¹³ , а также для создания конформационного ансамбля в белке с уникальным доменом Sh5 ¹⁴ . Однако, хотя предполагается гораздо более широкое применение в фолдинге белков, этот метод неэффективен в белках, где конформации разделены большими барьерами свободной энергии, что приводит к плохому смешиванию реплик между высокотемпературным режимом и низкотемпературным режимом. Вероятно, это связано с отсутствием энергетической компенсации горячего растворенного вещества и холодного растворителя. Включение подмножества случайных молекул воды в темперируемую центральную группу улучшает перемешивание, но за счет плохого масштабирования при размере системы 9.1823 15 . Совсем недавно появилась обобщенная версия REST (gREST), которая масштабирует гамильтониан на основе частиц, а также энергетических членов ¹⁶, что еще больше сокращает количество реплик и в значительной степени устраняет проблемы масштабируемости. Однако, поскольку степень отпуска ограничена несколькими энергетическими терминами, методу требуется больше времени для сходимости при выборке конформации. Это говорит о том, что преодоление барьера свободной энергии по-прежнему является узким местом для этого класса методов.

Как правило, методы параллельного отпуска страдают, когда барьеры между свернутым/развернутым состояниями и промежуточными состояниями высоки или когда переходное состояние носит диффузионный характер с большими энтропийными барьерами, замедляющими конформационные обмены ¹⁷ . Нереально сокращенное время пребывания в метастабильных состояниях препятствует переключению между конформационными бассейнами. В этих случаях трение между полипептидной цепью и растворителем модулирует скорость сворачивания или разворачивания белка ¹⁸ . В этой работе мы предлагаем гибридный метод обмена репликами (далее именуемый обмен репликами с гибридным темперированием (REHT)), который дифференциально и оптимально нагревает как растворенное вещество, так и растворитель. Другими словами, наряду с гамильтоновым масштабированием каждой реплики, которая эффективно нагревает растворенный белок, реплики также связаны с различными высокотемпературными ваннами, которые нагревают систему, включая частицы растворителя. Выбранный диапазон температур ванны реплик достаточно мал, чтобы разница в энергии из-за самодействия растворителя была минимальной и не приводила к проблеме масштабируемости. В то же время оптимальное темперирование растворителя вместе с растворенным веществом обеспечивает эффективную перестройку гидратной оболочки, которая работает совместно с конформационным изменением белка, тем самым помогая преодолевать более крупные барьеры и, в частности, энтропийные барьеры. Мы демонстрируем это, применяя протокол к разнообразному набору белков, которые сильно различаются по размеру и сложности лежащего в основе ландшафта свободной энергии. Выбор белковых молекул варьируется от простых модельных систем, таких как дипептид аланина, до быстрых папок, таких как TRP-Cage и β-шпилька, и белков со сложным энергетическим ландшафтом, таких как IDP (пример: гистатин-5) и метаморфные белки (пример: RFA- ЧАС).

Результаты

Мы исследовали многомерные ландшафты свободной энергии белков различной сложности, используя метод REHT, и сравнили его эффективность с современным моделированием REST2 ¹¹. Для этого мы использовали модуль HREX PLUMED, первоначально разработанный для выполнения моделирования обмена гамильтоновыми репликами ¹⁹ . Модуль очень гибкий и позволяет одновременно использовать различные смещения в репликах, такие как гамильтониан, коллективная переменная, температура и давление. Для метода REHT мы включаем дополнительное температурное смещение в репликах вместе с гамильтоновым масштабированием белкового растворенного вещества, для которого мы выводим и применяем соответствующие подробные критерии обмена баланса. Подробный вывод критериев обмена с учетом подробного баланса представлен в разделе «Методы». Короче говоря, критерии обмена для REHT даются следующим образом:

$${\Delta}_{{{nm}}}\left( {{\rm{REHT}}} \right) = — \left[ \begin{array}{l}({\it{\ бета }} _ {{n}} \ lambda _ {{n}} — {{\ beta }} _ {{m}} \ lambda _ {\ rm {m}}) \ left [ {{{H}} _{{{pp}}}\left( {{{X}}_{{n}}} \right) — {{H}}_{{{pp}}}\left( {{{X}} _{{m}}} \right)} \right]\\ + \left( {\it{\beta}}_{{n}}\sqrt {\lambda _{\rm{n}}} — {\ it {\ beta}} _ {{m}} \ sqrt {\ lambda _ {\ rm {m}}} } \ right) \ left [ {{{H}} _ {{{pw}}} \ влево( {{{X}}_{{n}}} \right) — {{H}}_{{{pw}}}\left( {{{X}}_{{m}}} \right )} \right]\\ + \left( {{\it{\beta}}_{{n}} — {\it{\beta}}_{{m}}} \right)\left[ {{ {H}}_{{{ww}}}\left( {{{X}}_{{n}}} \right) — {{H}}_{{{ww}}}\left( {{ {X}}_{{m}}} \right)} \right]\end{массив} \right]$$

(1)

где, ${H}_{pp}\left( {X_{m|{n}}} \right)$, ${H}_{pw}\left( { X_{m|{n}}} \right)$ и ${H}_{ww}\left( {X_{m|{n}}} \right)$ указывает на внутрибелковый, белок– энергии взаимодействия воды и воды в репликах m ^th и n ^th. ${\it{\beta}}_{m|{n}}$ и ${\it{\lambda}}_{{m}|{n}}$ — соответствующие обратные температуры и гамильтониан коэффициент масштабирования двух реплик.

Хотя методологическое усовершенствование REHT берет свое начало в REST2, метод REHT оказывает значительное влияние на эффективность выборки, как будет продемонстрировано здесь, в этом разделе. Эффективность показана не только на простых модельных белках, но и на таких белках, как внутренне неупорядоченный гистатин-5 и метаморфические белки RFA-H. Различные системы, рассматриваемые в этой статье, показаны на рис. 1. Детали расчета всех систем представлены в дополнительной таблице 1.

Рис. 1: Список исследованных систем.

a Двугранное переключение дипептида аланина, b укладка Trp-Cage из полностью развернутой структуры, c укладка β-шпильки, d внутренне неупорядоченный гистатин-5 и e метаморфическое переключение в бактериях RFA-H исследуются с использованием современного подхода REST2 и REHT, разработанного в этой работе.

Изображение в натуральную величину

Качественно улучшенная выборка модельных белков с помощью REHT

Сначала мы проверяем эффективность выборки нашего метода параллельной закалки на хорошо известных модельных системах, таких как аланин-дипептид, TRP-клетка и β-шпилька. Моделирование TRP-клетки и β-шпильки было инициировано из полностью расширенных конформаций физиологически релевантного цвиттерионного состояния ²⁰ (с заряженными концами). Для сравнения с современным методом выборки на основе MD моделирование также выполняется с помощью REST2 ^10,11,14 . Смешивание реплик двух симуляций в обеих системах показано на дополнительных рисунках. 1 и 2.

В ходе моделирования методы REHT и REST2 обеспечивают переход развернутой исходной конформации в нативную свернутую конформацию с почти идеальным совпадением с экспериментально найденной нативной структурой (0,4 Å среднеквадратичное отклонение (RMSD)) как показано на рис. 2а и дополнительном рис. 3а. Важно отметить, что при РВТ мы наблюдаем более быстрые переходы между складчатыми и развернутыми бассейнами. Эволюция RMSD во времени указывает на то, что метод REHT отбирает свернутые структуры двух белков в масштабах времени менее 100 нс (рис. 2b) и создает свернутое состояние в 6 из 12 реплик (дополнительные рисунки 3b, 4). Моделирование REST2 демонстрирует складчатую структуру TRP-клетки (рис. 2b) и β-шпильки (ссылка 9).1823 16 ) около 300 нс. Более того, в этих симуляциях только 1–2 реплики из 8 реплик складываются независимо (дополнительный рисунок 5 и ссылка ¹⁶). Ландшафты свободной энергии в зависимости от RMSD и радиуса вращения для базовой реплики TRP-клетки, смоделированной с помощью REHT и REST2, представлены на рис. 2c и рис. 2d соответственно. Предсказываемый методом РВТ барьер свободной энергии (~2 ккал/моль) хорошо совпадает с предполагаемым барьером свободной энергии ~2,1 ккал/моль ^21,22 , в то время как в моделировании REST2 наблюдается больший барьер около ~ 6 ккал / моль. Однако следует отметить, что оценка энергетического барьера зависит от выбора координат реакции, используемых для проектирования ландшафта. Для идеальных координат реакции, которые охватывают самые медленные пути реакции сворачивания белка, может потребоваться оптимизация координат реакции с помощью таких методов, как выборка на основе пути и другие линейные и нелинейные комбинации методов ^23,24,25,26 . Кроме того, сгенерированные карты свободной энергии будут иметь смысл только в том случае, если моделирование будет эргодичным. Мы оценили эргодичность, сравнив конформационные распределения базовой реплики на двух равных половинах траектории, аналогично предложенной группой Дейва Тирумалаи 9.1823 27 и группа Брюса Берна ¹⁰ . Результаты показали, что REHT сходится быстрее, чем REST2. (См. дополнительные рисунки 6, 7 и дополнительное примечание 1).

a Структурное наложение между изначально свернутой структурой ЯМР (синий) и свернутой структурой Trp-клетки, созданной с помощью REHT (желтый, полученной на базовой реплике). б г. Эволюция во времени среднеквадратического отклонения скелета белка из структуры ЯМР вдоль одной из успешно свернутых реплик моделирования REHT (вверху) и REST2 (внизу). Эволюция RMSD других складчатых реплик показана на дополнительных рисунках. 4 и 5. c , d Ландшафт свободной энергии Trp-Cage, показанный как функция радиуса вращения (Rg) и среднеквадратического отклонения от структуры ЯМР. Ландшафт показан для ансамблей, собранных на базе реплики c ) моделирования REHT и d Моделирование REST2.

Изображение в натуральную величину

Ускоренная выборка координаты «медленной» реакции (коллективная переменная) также видна в дипептиде аланина, квинтэссенции модельной системы для событий пересечения барьера в области разработки передовых биофизических методов отбора проб. Мы подробно обсуждаем это в дополнительном примечании 2 под заголовком «Двугранный переключатель в дипептиде аланина». Короче говоря, мы показываем, что относительно медленно изменяющийся угол ϕ карты Рамачандрана часто выбирается в методе REHT (дополнительные рисунки 8, 9). ) с большим количеством реплик (4 из 5), также демонстрирующих этот переход.

Ансамбль выборки гибких IDP с высоким зарядом и низкой гидрофобностью

Точная конформационная выборка IDP является серьезной проблемой в области молекулярного моделирования, где обычные силовые поля не могут точно воспроизвести свойства IDP. Было предложено несколько решений для устранения проблем переносимости силового поля, которые широко применялись к ВПЛ ^28,29,30,31 . Что выделяется в этих улучшениях, так это необходимость иметь сбалансированные взаимодействия белок-вода помимо необходимых изменений в параметрах белков ^32,33 . Кроме того, методы выборки редких событий часто используются в сочетании с этими улучшенными силовыми полями для точного захвата конформационного ландшафта IDP, как показано для P53 ³⁴, α-синуклеина ³⁵, островкового амилоидного полипептида ³⁶, амилоидного полипептида. β ^37,38 и NCBD ВПЛ ³⁹ . Недавно REST2 в сочетании со специфичным для IDP силовым полем (Amberff03ws) и моделью воды (TIP4P/2005s) был успешно использован для получения экспериментально согласованного ансамбля в Sh5UD ¹⁴.

Несмотря на эти успехи, существует множество ИДП, для которых данные моделирования показывают разительные отклонения от экспериментальных результатов. Например, в длинном антимикробном пептиде гистатине-5 (His-5), состоящем из 24 остатков, ансамбль, созданный с помощью моделирования, существенно отклоняется от экспериментальных данных по круговому дихроизму (КД), ядерному магнитному резонансу (ЯМР) и малоугловому X-. измерения рассеяния лучей (SAXS) ^40,41 . Образцы His-5 не берутся точно даже с самыми современными силовыми полями ^40,41, что указывает на отсутствие их переносимости через ВПЛ с различным диапазоном характеристик заряда и гидропатии. Мы иллюстрируем график заряд-гидропатия (CH) различных IDP на рис. 3a. График ясно показывает, что успешно охарактеризованные белки (p53, AB42, NCBD, Sh5UD) находятся на линии, разделяющей складчатую и развернутую области, или рядом с ней, что указывает на глобулярную природу этих IDP до расплавления. His-5 на другом конце расположен на дальнем конце графика CH с очень минимальной гидрофобностью и более высокими зарядами.

Рис. 3: Описание ансамбля внутренне неупорядоченного гистатина-5.

a График заряд-гидропатия, показывающий уникальность гистатина-5, расположенного в неупорядоченной зоне с более низкой средней гидрофобностью, в отличие от других успешно изученных IDP, которые существуют в складчатой зоне или рядом с ней. b Сравнение экспериментального (черный) и теоретического профиля SAXS, усредненного по ансамблю, представленного в виде графика Кратки. Теоретический прогноз был сделан для последних 250 нс невзвешенных траекторий, соответствующих базовой реплике моделирования REHT и REST2. Распределение Rg для ансамблей, полученных при моделировании REST2 (красный) и REHT (синий), показано на вставке. c Сравнение усредненных по ансамблю химических сдвигов атомов Hα, предсказанных на основе моделирования REHT и REST2 (для той же траектории 250 нс), со ссылкой на экспериментальные химические сдвиги ЯМР. d Слабо воронкообразный диффузионный энергетический ландшафт гистатина-5, исследованный с помощью моделирования REHT, показан как функция Rg и площади поверхности, доступной для растворителя (SASA).

Полноразмерное изображение

Мы выбрали конформационный ландшафт His-5 с использованием REHT и REST2 (см. Дополнительный рисунок 10 для смешивания реплик) и проверили точность сгенерированного ансамбля по сравнению с различными экспериментальными средними свойствами ансамбля. Для начала мы оценили содержание вторичной структуры этого пептида, анализируя диэдры основной цепи всех остатков. Данные компакт-диска ⁴² показывает, что His-5 предпочитает образовывать структуры полипролина II (PPII), и склонность к PPII теряется при более высоких температурах. Карта Рамачандрана для His-5 (дополнительный рисунок 11) указывает на наиболее вероятное появление структур PPII, которые обычно не повторяются в обычных методах выборки IDP ⁴² . Интересно, что усиление выборки с помощью REHT или REST2 резюмирует склонность PPII-структур His-5 в качественном согласии с измерениями CD. Кроме того, температурно-зависимая потеря структуры PPII также правильно зафиксирована (дополнительный рисунок 11).

Мы также рассчитали наноразмерные структурные свойства His-5, измеренные экспериментально с помощью SAXS, который описывает общий размер и форму белка в растворе. Экспериментальные данные SAXS ⁴³ для His-5 при комнатной температуре и нейтральном pH были получены из лаборатории профессора Мари Скепо в Швеции. Результаты представлены на рис. 3b в виде безразмерного представления Кратки, которое качественно оценивает компактность и гибкость белка. Это можно получить из коэффициента формы, используя следующее уравнение: ( qRg ) ² I ( q )/ I (0) и нанесен на график против qRg . В случае компактных хорошо свернутых белков график Кратки демонстрирует колоколообразный пик в режиме низкой добротности и сходится к оси q в режиме высокой добротности. Наоборот, неупорядоченные белки, в зависимости от степени компактности, гибкости цепи и наличия структурированных участков, показывают разные кривые. Для полностью расширенных или полностью развернутых белков интенсивность в области с высоким q демонстрирует плато, за которым в некоторых случаях может следовать дальнейший рост ^44,45 . Как показано на рисунке, график Кратки His-5, полученный в результате эксперимента, демонстрирует характер очень гибкого и расширенного IDP. Профиль SAXS из данных ансамбля REHT (рис. 3b) близко совпадает с профилем эксперимента, тем самым усиливая его точность при точном построении ансамбля IDP. Мы считаем, что конформации IDP, которые находятся значительно дальше от пограничной области CH, гораздо больше подвержены влиянию стабильности, вызванной гидратацией. В таких случаях REST2 не подходит, поскольку он не обрабатывает окружающую воду и, следовательно, создает более компактный конфигурационный ансамбль белка, как видно из профиля SAXS и графика Rg (рис. 3b: вставка). Мы также сравниваем химические сдвиги атомов водорода, связанных с Cα, предсказанные методами REHT и REST2, с данными химических сдвигов ЯМР ⁴⁶ (рис. 3в). Химические сдвиги, предсказанные с помощью REHT, лучше соответствуют экспериментам, чем метод REST2.

После проверки ансамбля, сгенерированного REHT, с экспериментальными данными измерений КД, МУРР и ЯМР, мы воссоздаем карту свободной энергии His-5 при комнатной температуре в зависимости от различных структурных параметров (рис. 3d, дополнительный рис. . 12). Карта свободной энергии указывает скорее на низкоэнергетический ландшафт с плоским дном в широком диапазоне значений Rg (от 1,0–1,8 нм) и значений SASA (28–34 нм9).1823 2 ). Результаты показывают, что в условиях раствора пептид предпочитает существовать в полностью неупорядоченной конформации. Такая большая беспорядочность наделяет их способностью связывать различные мишени, что подтверждается протеомным анализом ⁴⁷ . Мы также проследили остаточную склонность к α-спирали, наблюдаемую в неводных растворах и модельных липидных везикулах, которая связана с ее кандидацидным функционированием ^46,48,49 . Однако мы не наблюдали никаких следов спиральности в ансамбле растворов (дополнительный рисунок 13), что позволяет предположить, что спиральный переход может быть адаптирован индуцированным образом при ассоциации с мембраной.

Напротив, ансамбль, сгенерированный REST2, создает воронкообразный ландшафт свободной энергии с ограничением при компактном значении Rg (дополнительный рисунок 12). Более того, для достижения конвергентного распределения выборки REST2 потребует в 12 раз больше процессорного времени, чем REHT (дополнительные рисунки 14–16 и дополнительное примечание 3). Сравнивая карты свободной энергии между REHT и REST2, можно легко сделать предположение о степени неоднородности, добавляемой к выборке методом REHT. Кроме того, мы количественно оценили гетерогенность ансамбля REST2 и REHT в базовой реплике путем измерения попарных расстояний между конформациями (дополнительное примечание 4) ^50,51 . Однако измерения (дополнительный рис. 17) объясняют большую неоднородность для REST2, несмотря на ограниченную выборку компактных состояний. Эти противоречивые результаты необходимо было согласовать, и мы ожидали, что одно из возможных объяснений этого несоответствия может быть связано с «гетерогенными компактными структурами», которые моделируются при моделировании REST2 для ансамбля His-5.

Чтобы проверить это, мы создали двумерную карту ансамбля на основе попарных конформационных расстояний с использованием многомерного масштабирования (MDS). MDS особенно полезен для визуализации матрицы расстояний в низкоразмерном пространстве при максимально возможном сохранении расстояний между объектами. Конформационная карта по координатам MDS представлена на рис. 4 как для REST2, так и для REHT. Раскрашивание каждой конформации соответствующим значением Rg (рис. 4а, б) показывает, что в REST2 действительно больше разнообразных компактных состояний (чем в REHT), которые распространяются по всему пространству. В то же время окраска на основе индекса реплик показывает, что отдельные компактные конформации происходят из разных реплик, которые занимают неперекрывающиеся и максимально разделенные области (для реплик № 2, 3, 4 и 7), как показано на рис. 4c. Этот результат ясно показывает, что в REST2 повышенная гетерогенность возникает в базовой реплике за счет обмена конформациями между репликами, застрявшими в разных локальных бассейнах компактных структур. (Конформационная ловушка отдельной реплики в REST2 также видна на дополнительных рисунках 15 и 18). С другой стороны, в REHT вклады независимых реплик существенно не отличаются и не отличаются друг от друга, и внутри одной реплики они отбирают разное пространство (рис. 4d).

Рис. 4: Конфигурационная карта ансамбля His-5, основанная на парном различии конформаций, показанных по двумерным осям MDS.

В a , b конформации ансамблей REST2 и REHT окрашены соответствующими значениями Rg , а в c , d они окрашены индексом реплики. Максимально разделенные неперекрывающиеся кластеры в REST2, отмеченные в c , указывают на захват конформаций в независимых репликах, которые в конечном итоге заменяются базовой репликой.

Полноразмерное изображение

Исчерпывающая выборка гетерогенных конформаций позволяет проводить процесс смешивания в REHT, который в противном случае приводит к образованию водоворотов в верхней и нижней зонах реплик, как это видно в REST2. По сути, обмены между репликами происходят в зонах, а межзональные обмены не происходят, что резко влияет на общую выборку. Такое поведение легко проявляется в больших сложных белках, таких как метаморфный RFA-H, как будет показано в следующем разделе.

Расшифровка переходных промежуточных продуктов метаморфического белка (RFA-H)

В отличие от ландшафтов со слабой множественной воронкой, обычно встречающихся у ВПЛ, метаморфические белки имеют глубокие множественные воронки, где каждая низкоэнергетическая впадина представляет собой отчетливую хорошо сложенную конформацию. Эти конформации переключаются при получении сигналов для выполнения различных функций. Среди многих представителей метаморфических белков, известных на сегодняшний день, RFA-H обладает сильно расходящимися складками с совершенно разными вторичными структурами. RFA-H представляет собой бактериальный регуляторный белок, в котором его С-концевой домен чередуется между всеми конформациями α-спирали и всеми конформациями β-листа в зависимости от наличия или отсутствия междоменных контактов соответственно (рис. 5a) ⁵² . Находясь в спиральной конформации, он активирует элементы транскрипции, в конформации β-листа он рекрутирует рибосомный белок и тем самым связывается с трансляцией ^53,54 . Переход между этими альтернативными конформациями обычно включает разворачивание одной конформации и рефолдинг в другую конформацию ⁵⁵ . Изучение этих белковых ландшафтов с помощью моделирования МД является очень сложной задачей, и редко предпринимались попытки с использованием методов смещения, таких как целевая МД или вспомогательная модель ГО 9.1823 56,58,58 .

Рис. 5: Конформационная метаморфоза RFA-H.

a Схематическое изображение двух нативных структур, разрешенных в экспериментах: α-спиральная складка CTD в присутствии NTD и β-складка при изолированной CTD. b Начальная и конечная структуры моделирования REHT. Спиралевидное состояние CTD при удалении NTD было выбрано в качестве исходной структуры (левый рисунок в b ). Структурное наложение сгенерированной окончательной симуляцией β-бочки (красный) на экспериментальную β-структуру (голубой) показано в правой части ( б ). c Проверка ансамбля, сгенерированного моделированием, путем сравнения предсказанных химических сдвигов Cα с экспериментальными сдвигами. Подогнанная линейная регрессия (синяя линия) указывает на точное соответствие между двумя наборами данных. d Ландшафт свободной энергии с двумя бассейнами RFA-H показан как функция среднеквадратичных отклонений от экспериментально обнаруженных α-спирали (2OUG) и β-листа (2LCL). Конформации в каждом из бассейнов, все α-спиральные и все β-листовые (I и VII), ранняя структура с потерей спиральности на обоих концах (II), промежуточная частично развернутая структура с остаточным содержанием α-спиралей (III ), а вдоль ландшафта показаны метастабильные структуры с открытыми β-листами (V и VI). Обратите внимание, что полностью развернутая структура (IV) находится на другой стороне двойного бассейна, и переход структуры α → β не обязательно должен проходить через полностью развернутую структуру, в отличие от метаморфического лимфотактина 9.1823 55 .

Изображение в натуральную величину

Мы приступили к изучению конформационной метаморфозы RFA-H в явной воде, используя наше беспристрастное моделирование REHT. То же самое было предпринято с использованием моделирования REST2, которое не дало надлежащего смешивания реплик даже при времени моделирования 250 нс на реплику (дополнительный рисунок 19) и, следовательно, было исключено. REHT начал показывать смешивание между репликами примерно на 100 нс, и прогоны были увеличены до 1000 нс на реплику для 25 реплик. В качестве исходной структуры использовали экспериментально полученное α-спиральное состояние (идентификатор PDB: 2OUG) С-концевого домена (CTD (номер остатка 115-162)) (рис. 5b). В отличие от предыдущих исследований с использованием целевого MD ^56,58 или модель с поддержкой GO с туннелированием обмена репликами ⁵⁷ метод REHT не включает в себя никакой информации о целевом состоянии. Несмотря на это, моделирование спонтанно преобразует RFA-H _CTD из спиральной структуры в конформацию β-бочонка. Анализ вторичной структуры ансамбля, сгенерированного при самой низкой температуре (310 K) реплики, показывает, что это преобразование происходит в течение 300 нс (дополнительный рисунок 20). Остатки, которые, как было показано, образуют β-листы, хорошо согласуются со структурой, полученной ЯМР (идентификатор PDB: 2LCL). Структурное наложение снимка, полученного в результате моделирования, на структуру ЯМР показано на рис. 5b, и их СКО рассчитано как 3,4 Å. Здесь уместно отметить, что предыдущее несмещенное моделирование МД с неявной моделью сольватации с использованием функции эффективной энергии EEF1 ⁵⁹, не может спонтанно произвести β-ствол. Потребовалось дополнительное уточнение с явным моделированием растворителя, чтобы получить бочкообразную структуру с СКО ~ 5 Å относительно экспериментальной структуры ⁶⁰ .

Для дальнейшего подтверждения наших результатов мы предсказали основные химические сдвиги сгенерированного с помощью моделирования ансамбля, полученного из реплики при комнатной температуре. Для этого анализа использовались последние 500 нс таймфреймы без какого-либо повторного взвешивания или ограниченного отбора. Предсказанные химические сдвиги Cα сравнивали со сдвигами, измеренными с помощью ЯМР-спектроскопии (рис. 5c). Рисунок ясно демонстрирует поразительное соответствие между предсказанными и измеренными значениями химического сдвига. После экспериментальной проверки мы проследили молекулярные детали механизма переключения сгиба по нашей траектории с атомарным разрешением, информацию, которую нельзя получить непосредственно из экспериментов. Для этого мы построили карту свободной энергии в зависимости от среднеквадратичных отклонений относительно экспериментально обнаруженных спиральных и бета-бочковых структур (рис. 5d). На карте показаны двойные бассейны, каждый из которых соответствует разным складкам RFA-H, где бассейны разделены барьером свободной энергии около 5 ккал/моль. Этот барьер соответствует переходу α → β, но не способствует обратному переходу. Этот аргумент основан на нашем наблюдении: с увеличением времени моделирования популяция β-конформации показывает увеличение, что указывает на (неконвергентный) более глубокий бассейн для β-структуры. (Дополнительный рис. 21) Для обратного перехода β → α эксперименты показывают, что N-концевое взаимодействие важно ⁵² . Чтобы подкрепить это утверждение, мы смоделировали дополнительное моделирование, начатое на основе β-структуры, полученной ЯМР, которая показывает стабильные структуры β-бочонка (дополнительный рисунок 22) и согласуется с наблюдениями ЯМР ⁵² .

В то время как бассейн свободной энергии, соответствующий α-спиральной структуре, демонстрирует воронкообразную архитектуру, бассейн β-цилиндрической структуры выглядит как неровный ландшафт, указывающий на возможную неоднородность в этом состоянии. Неоднородность, вероятно, создает энтропийный барьер и усложняет карту свободной энергии и тем самым ограничивает спонтанный переход из одного состояния в другое при использовании обычных передовых методов выборки. REHT показывает многообещающие результаты в преодолении как энтальпического, так и энтропийного барьеров и, следовательно, позволяет изучать сложные конформационные переходы IDP и белков-«трансформеров», таких как RFA-H. Этот метод также открывает возможности для изучения других белков-трансформеров, таких как белок хемокин-лимфотактин, белок контрольной точки веретена Mad2, CLIC1 ⁴ .

Модулированное закаливание самовоздействия воды облегчает преодоление энтропийного барьера и способствует конформационному поиску

Наш метод берет свое начало в REST2, где мы пытаемся решить проблемы, возникающие из-за «холодного растворителя», сохраняя при этом вычислительные требования. REHT показывает замечательные улучшения в выборке конвергентных и экспериментально согласованных ансамблей с использованием одного и того же силового поля. Кроме того, оба метода не накладывают смещения на базовую реплику ни прямо, ни косвенно из высокотемпературных реплик, что создает идентичные условия равновесного ансамбля (дополнительный рисунок 23). Несмотря на это, поразительная разница в качестве отбора проб связана с тем, как рассматривается самовоздействие воды в REHT и REST2. Сравнение свойств гидратных оболочек для двух методов дало некоторые очень интересные и показательные сведения о возможных причинах различий в отборе проб и значительно сократило время прохождения туда и обратно для REHT по сравнению с REST2.

Следует отметить, что траектория на базовой реплике не является непрерывной во времени (системные координаты обмениваются между разными репликами при каждом успешном обмене). Поэтому сравнение динамики гидратной оболочки базовых реплик привело бы к непонятным результатам. Поэтому мы решили провести одинаковый анализ непрерывных во времени траекторий для всех реплик. Мы извлекли и разделили траектории (по 1 нс каждая) из различных моментов времени моделирования (например: t = 50 нс, 100 нс, 150 нс и до 1000 нс). Мы выполнили расчет динамики переориентации воды в гидратной оболочке для всех траекторий с помощью инструмента MDAnalysis ⁶¹ . На дополнительном рисунке 24 мы показываем репрезентативный набор кривых затухания переориентации воды в одной из реплик (реплика 0 в разные моменты времени) Trp-клетки, смоделированной с помощью метода REHT.

Кривые могут быть представлены биэкспоненциальным затуханием ( C _{9{-x/\tau_{2}}\)) с набором быстрых ( τ ₁) и медленных ( τ ₂) констант распада. Мы извлекли эти константы затухания релаксации для всех отобранных непрерывных во времени траекторий TRP-клетки и His-5 с помощью моделирования REHT и REST2 и построили их кумулятивное распределение на дополнительных рисунках 25 и 6. Распределение быстрого компонента τ ₁ (~ 1 пс), который считается относительно независимым от температуры ⁶², демонстрируют аналогичные тенденции в моделях REST2 и REHT как для Trp-клетки, так и для His-5 (дополнительный рисунок 25). Наоборот, медленная компонента τ ₂ термоактивируется и его распределение заметно различается для методов REST2 и REHT (рис. 6а, б). Энергия активации медленной релаксации ( τ ₂ ) снижается при РВТ из-за различной обработки растворителя. Это дает сравнительно более быструю релаксацию, чем REST2, и в некотором смысле преодолевает узкие места «холодного растворителя», характерные для REST2.}

Рис. 6: Степень динамики гидратации и ее тесная связь с выборкой конформационного пространства.

На рисунке a , b мы показали кумулятивное распределение медленного компонента затухания ориентационной релаксации воды (τ ₂ ) в REST2 (красный) и REHT (синий) моделирования для Trp-клетки ( a ) и His-5 ( b ). В c – f мы спроецировали конформационное пространство клетки Trp (по RMSD на нативную структуру ЯМР и Rg) и His-5 (по SASA и Rg) с конформациями, закодированными цветом τ ₂ значение, указанное на цветовой полосе. Область со значительным энтропийным барьером выделена во всех системах. Поскольку в REST2 меньше реплик по сравнению с REHT (8 против 12 в Trp-клетке, 10 против 15 в гистатине-5), количество анализируемых точек также стало меньше в REST2.

Изображение в натуральную величину

Более быстрое затухание в водной ориентации способствует перестройке Н-связей белок-вода, что обеспечивает более быстрые конформационные переходы (дополнительный рисунок 26) ⁶³ . Таким образом, релаксация воды тесно связана с конформациями белка посредством Н-связей белок-вода. Затухание релаксации ориентации воды происходит медленнее в упорядоченных конформациях и быстрее в протяженных неупорядоченных конформациях белка. Мы показываем эту связь, изображая конформации белка, окрашенные значением релаксации ориентации воды τ ₂ на рис. 6c – f. Релаксация воды в моделировании REST2 и REHT ограничена в компактном и упорядоченном состояниях в одинаковой степени. Однако интересно, что основное отличие происходит от ландшафта, где преобладает энтропийный барьер, который соответствует развернутому/растянутому неупорядоченному состоянию до промежуточного состояния (обозначенного фигурными скобками). Эта область показывает относительно более быструю релаксацию в REHT, чем REST2, тем самым обеспечивая более гладкую поверхность для конформационных переходов из развернутого в промежуточное состояние. Мы считаем, что это приведет к уменьшению энтропийного барьера между развернутым и промежуточным состояниями в REHT, чем в REST2. Далее вниз по склону к компактному состоянию вода релаксирует гораздо медленнее, и энтальпийные взаимодействия, которые имеют тенденцию усиливаться при образовании межостаточных контактов (в случае свернутых белков), обычно управляют процессом фолдинга. ИДП, в которых энтальпийная компенсация слабее (из-за низкой гидрофобности и высокого суммарного заряда), благоприятствуют неупорядоченным состояниям.

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

Обсуждение

В этой работе мы разрабатываем масштабированный гамильтониан, который по-разному рассматривает взаимодействие белка и растворителя в зависимости от температуры в структуре обмена репликами. По существу, дизайн гамильтониана в нашем методе (REHT) позволяет быстрее затухать динамике ориентации воды, что, в свою очередь, улучшает конформационную выборку белков. Мы обнаружили, что ускоренная термодинамическая выборка в REHT компенсирует дополнительные вычислительные затраты, связанные с умеренно большим количеством реплик из-за включения взаимодействий воды в переработанный гамильтониан для обмена репликами. Структурный ансамбль с высоким разрешением для множества белков, полученный с помощью нашего моделирования REHT, превосходно согласуется со средними наблюдаемыми по ансамблю, полученными из ЯМР, SAXS, CD и других биофизических экспериментов без необходимости какого-либо повторного взвешивания. Этот метод особенно подходит для очень гибких IDP, таких как His-5, где динамика сольватации стабилизирует и стимулирует сосуществование нескольких вырожденных расширенных состояний пептида на поверхности свободной энергии, которая имеет несколько мелких бассейнов. Большие барьеры свободной энергии в метаморфических белках с множеством четко очерченных бассейнов, имеющих разнообразно свернутые конформации, обычно нелегко преодолеть с помощью обычных методов. Мы показываем, что REHT способен проводить выборку через барьеры метаморфических белков, выявлять возможные промежуточные продукты перехода и решать их конформационный ансамбль. Мы считаем, что при надлежащем сочетании с известными экспериментальными данными высокоточная информация о структурном ансамбле из неограниченных REHT-симуляций может быть эффективно использована для выборки и, при необходимости, для дальнейшей минимизации невязки с экспериментальными наблюдаемыми с использованием интегративной моделирующей структуры ^64,65,66 .

Методы

Вывод метода REHT

Мы предоставляем теоретические основы различных версий методов обмена репликами в дополнительном примечании 5. Здесь мы выводим подробное условие обмена баланса для метода REHT со специально разработанным гамильтонианом, который дифференциально обрабатывает растворитель и растворенное вещество в диапазоне температур.

Рассмотрим набор реплик, смоделированных при моделировании обмена репликами, как { X ₁ , X ₂ … X _n }. Как правило, реплики различаются по температуре ( Ti ), но используют идентичную функцию Гамильтона (температурный обмен репликами) или наоборот (гамильтоновский обмен репликами). В нашем гибридном подходе мы изменяем как температуру, так и гамильтониан в репликах. Следовательно, реплики можно обозначить как { X _m , H _m ( X _m ), T _m }, where X _m , H _m ( X _m ), и T _m соответственно представляют собой конфигурацию, функцию потенциальной энергии и температуру реплики m .

Поскольку реплики не взаимодействуют друг с другом, равновесная вероятность этого большего ансамбля может быть просто получена путем произведения коэффициентов Больцмана каждой реплики. 9N \frac{1}{{Z_i}}\exp \left( { — \beta _iH_i\left( X \right)} \right),$$

(2)

где β _i обозначает обратную температуру (1/ k _B T ), а Z _i представляет конфигурационную статистическую сумму.

Рассмотрим обмен конфигурациями между парой реплик m и n.

$$\left\{ {X_m,\,H_m\left( {X_m} \right),\,T_m} \right\} \to \left\{ {X_n,\,H_m\left( {X_n} \right),T_m} \right\}\\ \left\{ {X_n,\,H_n\left( {X_n} \right),\,T_n} \right\} \to \left\{ {X_m,\ ,H_n\left( {X_m} \right),T_n} \right\}$$

Плотность вероятности состояний до и после обмена задается следующим образом: {after} = [\exp — [\beta_mH_m(X_n) + \beta_nH_n(X_m)]] / Z $$

Подробное условие баланса и соответствующая вероятность перехода для этого обмена задаются выражением

$$\rho_ {до} {\Pi} \left( {X_m \to X_n} \right) = \,\rho_{after} {\Pi} \left( {X_n \to X_m} \right) \\ {\Pi} = \frac{\rho_{после}}{\rho_{до}} = \frac{{\Pi} \left ({X_m \to X_n} \right)} {{\Pi} \left ({X_n \to X_m } \справа)}$$

(3)

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

$${\Pi} = \frac{{\exp — [\beta _mH_m\left( {X_n} \ справа) + \beta _nH_n\left( {X_m} \right)]}}{{\exp — [\beta _mH_m\left( {X_m} \right) + \beta _nH_n\left( {X_n} \right)] }}$$

(4)

$$= \exp — \left[ {\beta _mH_m\left( {X_n} \right) + \beta _nH_n\left({X_m} \right) — \beta _mH_m \left( {X_m} \right) — \beta _nH_n\left( {X_n} \right)} \right]$$

(5)

$$= \exp ( — {\Delta}_{nm})$$

(6)

где } = \beta_n\left[ {H_n\left( {X_m} \right) — H_m\left( {X_m} \right)} \right] + \beta _m\left[ {H_m\left( {X_n} \ right) — H_n\left( {X_n} \right)} \right]\\ — (\beta _n — \beta _m)\left[ {H_n\left( {X_n} \right) — H_m\left( {X_m } \right)} \right]\end{array}$$

(7)

По критериям Метрополиса вероятность принятия обмена X _m → X _n становится,

{*{20}{c}} 1\hfill&if\,{\Delta}_{нм} \le 0 \\ \exp ( — {\Delta}_{нм})&if\,{\Delta}_{нм } \,> \, 0 \end{array}} \right. $$

(8)

Необработанный вывод из первого принципа приведен в следующей ссылке github (https://github.com/codesrivastavalab/ReplicaExchangeWithHybridTempering /blob/master/REHT-ShareFiles/reht-derivation.pdf).

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

$$H_m = \lambda _m\,H_{pp} + \sqrt {\lambda _m} \,H_{pw} + H_{ww}$$

(9)

где обозначают коэффициент масштабирования гамильтониана в реплике m. H _pp , H _pw и H _ww – потенциальная функция взаимодействия белок–вода, белок–вода.

Рекомбинация разности энергий из-за смещения температуры (уравнение (7)) и смещения гамильтониана, как в уравнении. (9), Δ _нм для РВТ становится,

$$= \; \beta _n\left[ {\left({\lambda _n — \lambda _m} \right)\left({H_{pp}} \right.\left({X_m} \right) + \left({\sqrt {\ lambda _n} — \ sqrt {\ lambda _m} } \ right) H_ {pw} \ left ({X_m} \ right)} \ right] \\ + \ beta _m \ left [ {\ left ( {\ lambda _m — \lambda _n} \right)\left( {H_{pp}} \right. \left( {X_n} \right) + \left( {\sqrt {\lambda _m} — \sqrt {\lambda _n} } \right)H_{pw}\left( {X_n} \right)} \right]\\ — \left( {\beta _n — \beta _m} \right)\left[ \begin{array}{l} \lambda _nH_{pp}\left( {X_n} \right) + \sqrt {\lambda _n} H_{pw}\left({X_n} \right) + H_{ww}\left( {X_n} \right) — \lambda _mH_{pp}\left( {X_m} \right)\\ — \sqrt {\lambda _m} H_{pw}\left({X_m} \right) — H_{ww}(X_m)\end{ массив} \right]$$

(10)

Коэффициент H _pp :

$$= \; \beta _n\left[ {\left({\lambda _{\mathrm{n}} — \lambda _{\mathrm{m}}} \right) + \left({\beta _n — \beta _m} \ справа) \ lambda _ {\ mathrm {m}}} \ right] H_ {pp} \ left ( {X_m} \ right) \\ + \ beta _m \ left [ {\ left ( {\ lambda _ {\ mathrm { m}} — \lambda _{\mathrm{n}}} \right) — \left( {\beta _n — \beta _m} \right)\lambda _{\mathrm{n}}} \right]H_{ pp}\left( {X_n} \right)\\ = -\! \left( {\beta _n\lambda _{\mathrm{n}} — \beta _m\lambda _{\mathrm{m}}} \right)\left[{H_{pp}\left({X_n} \ справа) — H_{pp}\left( {X_m} \right)} \right]$$

(11)

Коэффициент H _pw :

$$= \, \left[ {\beta _n\left({\sqrt {\lambda _{\mathrm{n}}} — \ sqrt {\ lambda _ {\ mathrm {m}}} } \ right) + (\ beta _n — \ beta _m) \ sqrt {\ lambda _ {\ mathrm {m}}} } \ right] H_ {pw } \ влево ( {X_m} \ вправо) \\ + \ влево [ {\ бета _ m \ влево ( {\ sqrt {\ lambda _ {\ mathrm {m}}} — \ sqrt {\ lambda _ {\ mathrm {n }}} } \right) — (\beta _n — \beta _m)\sqrt {\lambda _{\mathrm{n}}} } \right]H_{pw}\left({X_n} \right) \\ = — \!\left( {\beta _n\sqrt {\lambda _{\mathrm{n}}} — \beta _m\sqrt {\lambda _{\mathrm{m}}}} \right)\left[ {H_{pw}(X_n) — H_{pw}(X_m)} \right]$$

(12)

Коэффициент H _ww :

$$- \left( {\beta _n — \beta _m} \right)\left[ {H_{ww}\left( { X_n} \right) — H_{ww}\left( {X_m} \right)} \right]$$

(13)

Объединение уравнений. (11), (12) и (13),

$${\Delta}_{{\boldsymbol{nm}}}\left( {{{\mathrm{REHT}}}} \right) = — \ left[ \begin{array}{l}(\beta _n\lambda _{\mathrm{n}} — \beta _m\lambda _{\mathrm{m}})\left[{H_{pp}\left( {X_n} \right) — H_{pp}\left( {X_m} \right)} \right]\\ + \left( {\beta _n\sqrt {\lambda _{\mathrm{n}}} — \ бета _m\sqrt {\lambda _{\mathrm{m}}} } \right)\left[ {H_{pw}\left( {X_n} \right) — H_{pw}\left( {X_m} \right )} \right]\\ + \left( {\beta _n — \beta _m} \right)\left[ {H_{ww}\left( {X_n} \right) — H_{ww}\left( {X_m } \right)} \right]\end{массив} \right]$$

(14)

Список исследованных систем и подготовка атомистической модели

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

Исходная развернутая структура Trp-клетки и β-шпильки (C-концевая шпилька домена B1 в белке G) была получена путем моделирования соответствующих свернутых структур ЯМР (идентификатор PDB: 1l2Y и 1lE3 соответственно) при температуре 600 K в течение 10 нс. Для His-5 развернутая структура была построена с использованием компоновщика белка VMD путем ввода информации о последовательности (DSHAKRHHGYKRKFHEKHHSHRGY). Моделирование С-концевого домена RFA-H начинали с α-спиральной конформации (идентификатор PDB: 2OUG). Все белки (система 1–5 на рис. 1) сольватировали в кубическом боксе с минимальным расстоянием 1,2 нм от поверхности белка (в случае RFA-H используется 1,5 нм). Для всех систем использовалась 3-х местная жесткая модель воды TIP3P. Системы также нейтрализовали физиологическим раствором NaCl (0,15 М). Для топологических параметров быстро сворачивающихся белков мы использовали Amberff14SB, чтобы достоверно сравнить эффективность с более ранними моделями REST2 и gREST 9.1823 16 , тогда как для всех остальных систем (дипептид аланина, His-5 и RFA-H) использовалось силовое поле Charmm36m ²⁹.

Детали моделирования МД

Растворы смоделированных белков были первоначально минимизированы по энергии с использованием алгоритма наискорейшего спуска для 50 000 шагов, чтобы избежать плохих контактов. Затем минимизированную структуру термализовывали и уравновешивали последовательно в ансамблях NVT и NPT, каждый в течение 2 нс. Белок и растворитель соединяли отдельно до целевых температур с использованием модифицированного термостата Берендсена. Давление устанавливали на уровне 1 бар с помощью баростата Парринелло-Рахмана. Окончательное моделирование добычи было выполнено в ансамбле NVT с использованием термостата Nose-Hoover. Для расчета электростатических и ВДВ-взаимодействий использовалась отсечка 1 нм. Сетка частиц Эвальда использовалась для дальнодействующей электростатики. Для интегрирования уравнений движения использовался интегратор-чехарда с шагом по времени 2 fs. Все атомы водорода были ограничены с использованием алгоритма LINCS. Моделирование проводилось с помощью Gromacs-2016.5 с патчем Plumed-2.4.1. Все файлы параметров доступны в репозитории GitHub (https://doi.org/10.5281/zenodo.4361714) ⁶⁷ .

Параметры обмена репликами

Для всех симуляций мы использовали как схему REHT, разработанную в этой работе, так и современный метод REST2. Эти два метода различаются тем, как молекулы белка и воды рассматриваются в гамильтониане. REST2 смягчает только белок, но поддерживает температуру воды при комнатной температуре, масштабируя функцию потенциальной энергии растворенного вещества. Температура ванны, используемая в REST2, постоянна для всех реплик. С другой стороны, в методе REHT температура ванны слегка повышается до 340 K по мере того, как мы поднимаемся по лестнице реплики. Это в достаточной степени нагревает молекулы воды, обеспечивая ее эффективную динамику в методе РВТ. Для усиления динамики белка потенциалы растворенного белка масштабируются до максимального коэффициента ( λ ) ~0,5. Чтобы обеспечить достоверное сравнение, общая эффективная температура, реализованная на белке, одинакова в обоих моделированиях (дополнительная таблица 1). Однако из-за дополнительных степеней свободы, связанных с обработкой воды, количество используемых повторов для метода REHT несколько выше, чем для моделирования REST. Более подробная информация и скрипты для всей подготовки ввода (включая масштабирование силовых полей Amber14SB и charmm36m) приведены по ссылке на github: (https://doi. org/10.5281/zenodo.4361714) ⁶⁷ .

Теоретический анализ МУРР

Теоретический профиль МУРР для ансамбля HIS-5 был предсказан с помощью программы CRYSOL-2.8.4 ⁶⁸, которая вычисляет ориентационно-усредненную картину рассеяния с использованием мультипольного разложения по атомным координатам при рассмотрении сольватной оболочки с использованием сферических гармоник. Прогнозируемое значение сравнивают с экспериментальным форм-фактором His-5, полученным при нейтральном pH от Skepo et al. ⁴³ .

Теоретический анализ химических сдвигов

Скелетные химические сдвиги координат атомов His-5 и RFA-H были рассчитаны с помощью SPARTA+ (v2.90) ⁶⁹ , работающей на основе искусственной нейронной сети. Чтобы подтвердить наше моделирование, предсказанные сдвиги сравнивали с экспериментальными химическими сдвигами ЯМР, полученными из базы данных BMRB (https://bmrb.io), запись 17615 ⁵², и из литературы ⁴⁶.

Структурный анализ

Другие структурные параметры, такие как среднеквадратичное отклонение (RMSD), радиус вращения (Rg) и магистральные двугранные углы, были проанализированы с использованием соответствующих утилит Gromacs. Анализ вторичных структур белков проводили с помощью инструмента DSSP (v2.2.1). VMD использовали для визуализации траектории и рендеринга мультяшных изображений белка.

Анализ динамики гидратации

Динамические свойства гидратной оболочки рассчитаны с помощью ориентационной релаксации воды и затухания времени жизни водородных связей, реализованных в пакете MDAnalysis (v 0.19.2) ⁶¹ . Для этого анализа использовалась непрерывная траектория относительно времени моделирования. Ориентационная релаксация по существу свидетельствует о свободе вращения молекул воды в сольватной оболочке. Это измеряется путем вычисления вращательной автокорреляционной функции второго порядка двух векторов: одного вдоль связи ОН, а другого вдоль дипольного момента воды, как указано как: ) = P_2\left( {\шляпа u_{t_0}. \шляпа u_{t_{0 + \tau}}} \right)\), где, P ₂ ( x ) — второй полином Лежандра, а $\hat u$ — единичный вектор. Точно так же мы измеряем постоянство взаимодействия между белком и молекулами воды, вычисляя автокорреляционную функцию времени жизни водородной связи следующим образом: $C_{HB}\left( \tau \right) = \frac{{\mathop { \sum}\nolimits_{ij} h_{ij}\left( {t_0} \right)h_{ij}\left( {t_{0 + \tau}} \right)}}{{\ mathop {\sum} \nolimits_{ij} h_{ij}\left( {t_0} \right)}}$, где Н-связь между парой i и j в момент времени t , ($h_{ij}\left( t \right)$ считается равным 1, если геометрическое расстояние (<3,5 Å) и угол (>120°) $h_{ij}\left( t \right) = 0$ в противном случае. Мы рассмотрели два типа Н-связей белок-вода: «непрерывная Н-связь», когда молекула воды непрерывно участвует в Н-связях -связь и «прерывистая Н-связь», когда Н-связь сохраняется при прерывистой смене молекул воды

Расчеты изменения свободной энергии

Относительная свободная энергия Гиббса равновесного ансамбля вычисляется как функция двух координат реакции следующим образом:

$${\Delta}G_{(R1,R2)} = — k_BT\ln \frac{{P_{ \left( {R1,R2} \right)}}}{{P_{{\mathrm{Max}}}}},$$

(15)

, где k _B представляет Больцмана постоянная, T – температура. $P_{\left( {R1,R2} \right)}$ обозначает вероятность состояний по двум координатам реакции, которая рассчитывается с использованием схемы k-ближайших соседей и P _Max обозначает максимальную вероятность. Трехмерное представление поверхности свободной энергии было построено с использованием Matlab.

Измерение конформационной неоднородности и многомерного масштабирования

Расчеты ансамблевой неоднородности подробно описаны в СИ. Короче говоря, мы оценили неоднородность (несходство или расстояние между конформациями) путем измерения попарного косинусного расстояния ⁵⁰ и добротности ⁵¹ между конформациями. Парные конформационные расстояния ($n(n — 1)/2$ значения косинусного расстояния) затем встраиваются в двумерную конфигурационную карту n конформаций с использованием многомерного масштабирования таким образом, чтобы исходные парные расстояния сохранялись наилучшим образом ⁷⁰ .

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

Дополнительная информация о дизайне исследования доступна в Резюме отчета об исследовании природы, связанном с этой статьей.

Доступность данных

Данные, подтверждающие выводы этой рукописи, можно получить у соответствующего автора по обоснованному запросу. Необработанные данные, лежащие в основе линейных графиков и точечных диаграмм текущего исследования, также включены в эту статью в виде файлов txt в папке в репозитории github (https://doi.org/10.5281/zenodo.4361714) ⁶⁷ .

Доступность кода

Подробная информация о настройке моделирования REHT и сценарии для создания входных файлов доступны в том же репозитории github, https://doi.org/10.5281/zenodo.4361714 ⁶⁷.

Ссылки

Фреддолино, П.Л., Харрисон, С.Б., Лю, Ю. и Шультен, К. Проблемы моделирования свертывания белков: шкала времени, представление и анализ. Нац. физ. 6 , 751–758 (2010)..
Вейтшанс, Т., Климов, Д. и Тирумалай, Д. Кинетика сворачивания белков: временные рамки, пути и энергетические ландшафты с точки зрения свойств, зависящих от последовательности. Сложить. Дес. 2 , 1–22 (1997).

КАС пабмед Статья Google ученый
Онучич, Дж. Н. и Волинс, П. Г. Теория сворачивания белков. Курс. мнение Структура биол. 14 , 70–75 (2004).
КАС пабмед Статья Google ученый
Porter, L.L. & Looger, L.L. Существующие белки с переключением укладки широко распространены. Проц. Натл акад. науч. США 115 , 5968–5973 (2018).

КАС пабмед Статья ПабМед Центральный Google ученый
Рёдер, К., Джозеф, Дж. А., Хусик, Б. Э. и Уэльс, Д. Дж. Энергетические ландшафты для белков: от одиночных воронок до многофункциональных систем. г., ав. Теория Симул. 2 , 1800175 (2019).

Артикул КАС Google ученый
«>
Дайсон, Х.Дж. и Райт, П.Е. Внутренне неструктурированные белки и их функции. Нац. Преподобный Мол. Клеточная биол. 6 , 197–208 (2005).

КАС пабмед Статья Google ученый
Томпа П., Шад Э., Тантос А. и Калмар Л. Внутренне неупорядоченные белки: новые специалисты по взаимодействию. г. мнение Структура биол. 35 , 49–59 (2015).

КАС пабмед Статья Google ученый
Уверский В. Н. Танцующие белковые облака: странная биология и хаотическая физика внутренне неупорядоченных белков. J. Biol. хим. 291 , 6681–6688 (2016).

КАС пабмед ПабМед Центральный Статья Google ученый
Sugita, Y. & Okamoto, Y. Метод молекулярной динамики с обменом репликами для укладки белков. Хим. физ. лат. 314 , 296–297 (1999).

Артикул Google ученый
Лю, П., Ким, Б., Фризнер, Р. А. и Берн, Б. Дж. Реплика обмена с растворенным закаливанием: метод отбора проб биологических систем в явной воде. Проц. Натл акад. науч. США 102 , 13749–13754 (2005 г.).

ОБЪЯВЛЕНИЯ КАС пабмед Статья ПабМед Центральный Google ученый
Ван, Л., Фризнер, Р. А. и Берн, Б. Дж. Обмен репликами с масштабированием растворов: более эффективная версия обмена репликами с темперированием растворов (REST2). J. Phys. хим. B 115 , 9431–9438 (2011).

КАС пабмед ПабМед Центральный Статья Google ученый
Смит, А. К., Локхарт, С. и Климов, Д. К. Эффективен ли обмен репликами с темперированием растворенного вещества для выборки конформационных ансамблей пептида Aβ? J. Chem. Теория вычисл. 12 , 5201–5214 (2016).

КАС пабмед Статья Google ученый
Хуанг, К. и Гарсия, А. Е. Ускорение латерального уравновешивания в смешанных липидных бислоях с использованием обмена репликами с темперированием растворенного вещества. г. J. Chem. Теория вычисл. 10 , 4264–4272 (2014).

КАС пабмед ПабМед Центральный Статья Google ученый
Shrestha, U. R. et al. Генерация конфигурационного ансамбля внутренне неупорядоченного белка на основе беспристрастного моделирования молекулярной динамики. Проц. Натл акад. науч. США 116 , 20446–20452 (2019).

КАС пабмед Статья ПабМед Центральный Google ученый
Huang, X. et al. Обмен репликами с закалкой раствором: эффективность в крупномасштабных системах. J. Phys. хим. B 111 , 5405–5410 (2007).

КАС пабмед ПабМед Центральный Статья Google ученый
Камия М. и Сугита Ю. Гибкий выбор области растворенных веществ при обмене репликами с темперированием растворенных веществ: применение к моделированию сворачивания белков. J. Chem. Физ . 149 , 072304 (2018).
Нимейер, Х. Насколько эффективна молекулярная динамика обмена репликами? Аналитический подход. J. Chem. Теория вычисл. 4 , 626–636 (2008).

КАС пабмед Статья Google ученый
Pradeep, L. & Udgaonkar, JB. Диффузионный барьер в разворачивании небольшого белка. Дж. Мол. биол. 366 , 1016–1028 (2007).

КАС пабмед Статья Google ученый
«>
Bussi, G. Гамильтонов обмен репликами в GROMACS: гибкая реализация. Мол. физ. 112 , 379–384 (2014).

ОБЪЯВЛЕНИЯ КАС Статья Google ученый
English, C.A. & García, A.E. Заряженные концы на trp-клетки придают шероховатость складчатому энергетическому ландшафту. J. Phys. хим. Б 119 , 7874–7881 (2015).

КАС пабмед Статья Google ученый
Нейдиг, Дж. В., Фесинмейер, Р. М. и Андерсен, Н. Х. Разработка белка из 20 остатков. Нац. Структура биол. 9 , 425–430 (2002).

КАС пабмед Статья Google ученый
Линдорф-Ларсен, К., Пиана, С., Дрор, Р. О. и Шоу, Д. Э. Как складываются быстро сворачивающиеся белки. Наука 334 , 517–520 (2011).

ОБЪЯВЛЕНИЯ КАС пабмед Статья Google ученый
«>
Бест, Р. Б. и Хаммер, Г. Координаты и скорости реакции по путям перехода. Проц. Натл акад. науч. США 102 , 6732–6737 (2005 г.).

ОБЪЯВЛЕНИЯ КАС пабмед Статья ПабМед Центральный Google ученый
Перес-Эрнандес Г., Пол Ф., Джорджино Т., Де Фабритис Г. и Ноэ Ф. Идентификация параметров медленного молекулярного порядка для построения марковской модели. J. Chem. физ. 139 , 15102 (2013).

Артикул КАС Google ученый
Тивари, П. и Берн, Б. Дж. Оптимизация спектральной щели параметров порядка для выборки сложных молекулярных систем. Проц. Натл акад. науч. США 113 , 2839–2844 (2016).

ОБЪЯВЛЕНИЯ КАС пабмед Статья ПабМед Центральный Google ученый
Чен В. , Сидки Х. и Фергюсон А.Л. Нелинейное открытие медленных молекулярных режимов с использованием обратимых сетей VAMP без состояний. J. Chem. физ. 150 , 214114 (2019).

ОБЪЯВЛЕНИЯ пабмед Статья КАС Google ученый
Тирумалай Д., Маунтин Р. Д. и Киркпатрик Т. Р. Эргодическое поведение в переохлажденных жидкостях и стеклах. Физ. Rev. A, General Phys. 39 , 3563–3574 (1989).

ОБЪЯВЛЕНИЯ КАС Статья Google ученый
Лю, Х. и др. Обширные тесты и оценка силового поля CHARMM36IDPSFF для внутренне неупорядоченных белков и свернутых белков. Физ. хим. хим. физ. 21 , 21918–21931 (2019).

КАС пабмед ПабМед Центральный Статья Google ученый
Huang, J. et al. CHARMM36m: улучшенное силовое поле для свернутых и внутренне неупорядоченных белков. Нац. Методы 14 , 71–73 (2017).

КАС пабмед Статья Google ученый
Huang, J. & MacKerell, AD Jr Разработка силового поля и моделирование внутренне неупорядоченных белков. г. мнение Структура биол. 48 , 40–48 (2018).

КАС пабмед Статья Google ученый
Робустелли, П., Пиана, С. и Шоу, Д. Э. Разработка силового поля молекулярной динамики как для свернутого, так и для неупорядоченного состояния белка. Проц. Натл акад. науч. США 115 , E4758–E4766 (2018).

КАС пабмед Статья ПабМед Центральный Google ученый
Бест, Р. Б., Чжэн, В. и Миттал, Дж. Сбалансированное взаимодействие белок-вода улучшает свойства неупорядоченных белков и неспецифическую белковую ассоциацию. J. Chem. Теория вычислений . 10 , 5113–5124 (2014).
Сонг Д., Луо Р. и Чен Х.-Ф. Специфическое для IDP силовое поле ff14IDPSFF улучшает выборку конформеров внутренне неупорядоченных белков. J. Chem. Инф. Модель. 57 , 1166–1178 (2017).

КАС пабмед ПабМед Центральный Статья Google ученый
Миттал Дж., Ю Т. Х., Джорджиу Г. и Траскетт Т. М. Структурный ансамбль внутренне неупорядоченного полипептида. J. Phys. хим. B 117 , 118–124 (2013).

КАС пабмед Статья Google ученый
Ву, К.-П., Вайнсток, Д.С., Нараянан, К., Леви, Р.М. и Баум, Дж. Структурная реорганизация α-синуклеина при низком pH, наблюдаемая с помощью моделирования ЯМР и REMD. г. Дж. Мол. биол. 391 , 784–796 (2009).

КАС пабмед ПабМед Центральный Статья Google ученый
«>
Зерце, Г. Х., Миллер, К. М., Граната, Д. и Миттал, Дж. Поверхность свободной энергии внутренне неупорядоченного белка: сравнение между молекулярной динамикой обмена репликами температуры и метадинамикой обмена смещения. J. Chem. Теория вычисл. 11 , 2776–2782 (2015).

КАС пабмед Статья Google ученый
Дас, П., Матисяк, С. и Миттал, Дж. Рассмотрение неупорядоченных белков через вычислительный микроскоп. АКЦ Цент. науч. 4 , 534–542 (2018).

КАС пабмед ПабМед Центральный Статья Google ученый
Линкофф, Дж., Сасмал, С. и Хед-Гордон, Т. Задача отбора проб комбинированного силового поля при моделировании неупорядоченных пептидов амилоида-β. г. J. Chem. Физ . 150 , 104108 (2019).
Нотт, М. и Бест, Р. Б. Предварительно сформированный интерфейс связывания в несвязанном ансамбле внутренне неупорядоченного белка: данные молекулярного моделирования. PLoS вычисл. биол. 8 , e1002605 (2012 г.).

ОБЪЯВЛЕНИЯ КАС пабмед ПабМед Центральный Статья Google ученый
Kjaergaard, M. et al. Температурно-зависимые структурные изменения в внутренне неупорядоченных белках: образование а-спиралей или потеря полипролина II? г. Дж. хим. Теор. Вычисление 19 , 1555–1564 (2010).

КАС Google ученый
Baul, U., Chakraborty, D., Mugnai, M.L., Straub, J.E. & Thirumalai, D. Влияние последовательности на размер, форму и структурную гетерогенность в внутренне неупорядоченных белках. J. Phys. хим. B 123 , 3462–3474 (2019).

КАС пабмед ПабМед Центральный Статья Google ученый
Jephthah, S., Staby, L., Kragelund, B.B. & Skepö, M. Температурная зависимость внутренне неупорядоченных белков в моделировании: что мы упускаем? J. Chem. Теория вычисл. 15 , 2672–2683 (2019).

КАС пабмед Статья Google ученый
Cragnell, C., Durand, D., Cabane, B. & Skepö, M. Грубозернистое моделирование внутренне неупорядоченного белка гистатина 5 в растворе: моделирование методом Монте-Карло в сочетании с SAXS. Структура белков. Функц. Биоинформа. 84 , 777–791 (2016).

КАС Статья Google ученый
Receveur-Brechot, V. & Durand, D. Насколько случайными являются внутренне неупорядоченные белки? Перспектива рассеяния под малым углом. Курс. Белковый пепт. науч. 13 , 55–75 (2012).

КАС пабмед ПабМед Центральный Статья Google ученый
«>
Banks, A., Qin, S., Weiss, K.L., Stanley, C.B. & Zhou, H.X. Внутренне неупорядоченный белок проявляет как уплотнение, так и расширение в условиях скопления макромолекул. Биофиз. J. 114 , 1067–1079 (2018).

ОБЪЯВЛЕНИЯ КАС пабмед ПабМед Центральный Статья Google ученый
Брюэр, Д., Хантер, Х. и Лажуа, Г. ЯМР-исследования антимикробных слюнных пептидов гистатина 3 и гистатина 5 в водных и неводных растворах. г. Биохим. Клеточная биол. 76 , 247–256 (1998).

КАС пабмед Статья Google ученый
Моффа, Э. Б. и др. In vitro идентификация слюнных комплексов гистатина 5. PLoS ONE 10 , e0142517 (2015).

ПабМед ПабМед Центральный Статья КАС Google ученый
«>
Радж, П. А., Эдгертон, М. и Левин, М. Дж. Гистатин 5 слюны: Зависимость последовательности, длины цепи и спиральной конформации от кандидацидной активности. г. Дж. Биол. хим. 265 , 3898–3905 (1990).

КАС пабмед Статья Google ученый
Радж, П.А., Сони, С.Д. и Левин, М.Дж. Мембрано-индуцированная спиральная конформация активного кандидацидного фрагмента гистатинов слюны. J. Biol. хим. 269 , 9610–9619 (1994).

КАС пабмед Статья Google ученый
Лайл, Н., Дас, Р. К. и Паппу, Р. В. Количественная мера конформационной гетерогенности белка. J. Chem. физ. 139 , 121907 (2013).

ОБЪЯВЛЕНИЯ пабмед ПабМед Центральный Статья КАС Google ученый
Потоян Д. А. и Папоян Г. А. Регулирование ландшафтов связывания и складывания хвоста h5 посредством ацетилирования Lys-16. Проц. Натл акад. науч. США 109 , 17857–17862 (2012).

ОБЪЯВЛЕНИЯ КАС пабмед Статья ПабМед Центральный Google ученый
Burmann, M. et al. Переключение а-спирали на бочкообразный домен b превращает фактор транскрипции RfaH в фактор трансляции. Cell 150 , 291–303 (2012).

КАС пабмед ПабМед Центральный Статья Google ученый
Светлов В. и Нудлер Э. Развод моста между транскрипцией и трансляцией. Cell 150 , 243–245 (2012).

КАС пабмед Статья Google ученый
Зубер, П. К., Швеймер, К., Рёш, П., Арцимович, И. и Кнауэр, С. Х. Обратимое переключение фолда контролирует функциональный цикл фактора антитерминации RfaH. Нац. коммун. 10 , 702 (2019).

ОБЪЯВЛЕНИЯ КАС пабмед ПабМед Центральный Статья Google ученый
Tyler, R.C., Murray, NJ, Peterson, F.C. & Volkman, B.F. Взаимопревращение метаморфического белка в нативном состоянии требует глобального развертывания. Биохимия 50 , 7077–7079 (2011).

КАС пабмед Статья Google ученый
Ли, С. и др. Механизм конформационного перехода All-α в All-β RfaH-CTD: молекулярно-динамическое моделирование и модель марковского состояния. г. J. Chem. Теория вычисл. 10 , 2255–2264 (2014).

КАС пабмед Статья Google ученый
Бернхардт, Н. А. и Хансманн, У. Х. Э. Многоворонковый ландшафт белка с переключением укладки RfaH-CTD. J. Phys. хим. B 122 , 1600–1607 (2019).

Артикул КАС Google ученый
Рамирес-Сармьенто, К.А., Ноэль, Дж.К., Валенсуэла, С.Л. и Арцимович, И. Междоменные контакты контролируют переключение исходного состояния RfaH в двухконтурном ландшафте. PLoS-вычисление. биол. 11 , e1004379 (2015).

ОБЪЯВЛЕНИЯ пабмед ПабМед Центральный Статья КАС Google ученый
Лазаридис Т. и Карплюс М. Эффективная энергетическая функция белков в растворе. Структура белков. Функц. Биоинформа. 35 , 133–152 (1999).

КАС Статья Google ученый
Gc, JB, Bhandari, YR, Gerstman, B.S. & Chapagain, P.P. Молекулярно-динамические исследования конформационного преобразования α-спирали в β-ствол в факторе транскрипции RfaH. J. Phys. хим. B 118 , 5101–5108 (2014).

КАС пабмед Статья Google ученый
Мишо-Агравал, Н., Деннинг, Э. Дж., Вулф, Т. Б. и Бекштейн, О. MDAnalysis: набор инструментов для анализа моделирования молекулярной динамики. г. Дж. Вычисл. хим. 32 , 2319–2327 (2011).

КАС пабмед ПабМед Центральный Статья Google ученый
Yeh, Y. & Mou, C.-Y. Динамика ориентационной релаксации жидкой воды, изученная методом молекулярно-динамического моделирования. J. Phys. хим. B 103 , 3699–3705 (1999).

КАС Статья Google ученый
Широ, Г. и др. Трансляционная диффузия гидратной воды коррелирует с функциональными движениями в свернутых и внутренне неупорядоченных белках. Нац. Коммуна . 6 , 6490 (2015).
Кукос, П. И. и Бонвин, А. М. Дж. Дж. Интегративное моделирование биомолекулярных комплексов. Дж. Мол. Биол . https://doi.org/10.1016/j.jmb.2019.11.009 (2019 г.).
Вишванат С. и Сали А. Оптимизация представления модели для определения интегративной структуры макромолекулярных ансамблей. г. Проц. Натл акад. науч. США 116 , 540–545 (2019).

КАС пабмед Статья Google ученый
Шнейдман-Духовны Д., Пелларин Р. и Сали А. Неопределенность в интегративном структурном моделировании. Курс. мнение Структура биол. 28 , 96–104 (2014).

КАС пабмед Статья Google ученый
Appadurai, R., Nagesh, J. & Srivastsava, A. coderivastavalab/ReplicaExchangeWithHybridTempering: первый выпуск общих файлов REHT. https://doi.org/10.5281/zenodo.4361714 (2020 г.).
Свергун, Д., Барберато, К. и Кох, М. Х. Дж. CRYSOL — программа для оценки рассеяния биологических макромолекул в растворе рентгеновского излучения по атомным координатам. J. Appl. Кристаллогр. 28 , 768–773 (1995).

КАС Статья Google ученый
Shen, Y. & Bax, A. SPARTA+: скромное улучшение эмпирического предсказания химического сдвига ЯМР с помощью искусственной нейронной сети. г. Дж. Биомол. ЯМР 48 , 13–22 (2010).

КАС пабмед ПабМед Центральный Статья Google ученый
Борг И. и Гроенен П. Современное многомерное масштабирование: теория и приложения (Springer-Verlag, 2005).
Понсе, М. и др. Развертывание суперкомпьютера из 100 лучших для больших параллельных рабочих нагрузок: суперкомпьютер Niagara. In Proceedings of the Practice and Experience in Advanced Research Computing on Rise of the Machines (Learning) г. https://doi.org/10.1145/3332186.3332195 (Ассоциация вычислительной техники, 2019 г.).
Локен, К. и др. {SciNet}: уроки, извлеченные из создания энергоэффективной системы и центра обработки данных из списка 20 лучших. J. Phys. конф. сер. 256 , 12026 (2010).

Артикул Google ученый

Ссылки на скачивание

Благодарности

Авторы выражают благодарность Консорциуму SciNet HPC, ComputeCanada ^71,72 за вычислительные ресурсы и проф. Мари Скепо за данные SAXS Histatin-5. В КАЧЕСТВЕ. и А.Р. благодарит д-ра Джаганнатха Мондала, д-ра Ашока Сехара и д-ра Дебостути Гошдастидар за их ценные комментарии и предложения по рукописи. А.Р. благодарит Wellcome Trust – стипендию DBT India Alliance for Early Career (номер гранта: IA/E/18/1/504308). Дж.Н. благодарит DST-SERB за финансирование в рамках стипендии факультета Рамануджана (номер гранта: SB/S2/RJN-187/2017). В КАЧЕСТВЕ. также благодарит IISc-Bangalore и Министерство развития людских ресурсов Индии за стартовый грант и Департамент науки и технологий Индии за грант для начала карьеры (номер гранта: ECR/2016/001702). Это исследование также было поддержано Департаментом биотехнологии правительства Индии в форме партнерской программы IISc-DBT. Авторы с благодарностью признают поддержку программы FIST, спонсируемой Департаментом науки и технологий и UGC, Центром перспективных исследований и Министерством развития людских ресурсов Индии.

Author information

Authors and Affiliations

Molecular Biophysics Unit, Indian Institute of Science, Bangalore, Karnataka, India

Rajeswari Appadurai & Anand Srivastava
Solid State & Structural Chemistry Unit, Indian Institute of Science, Бангалор, Карнатака, Индия

Джаяшри Нагеш

Авторы

Раджесвари Аппадураи
Посмотреть публикации авторов

Вы также можете искать этого автора в PubMed Google Scholar
Jayashree Nagesh
Просмотр публикаций автора

Вы также можете искать этого автора в PubMed Google Scholar
Anand Srivastava
Просмотр публикаций автора

Вы также можете искать этого автора в PubMed Google Scholar

Contributions

A. R. и в качестве. задумал и спроектировал исследование; А.Р. проведенное исследование; Дж.Н. предоставленные вычислительные ресурсы; А.Р., Дж.Н. и А.С. проанализированные данные; и А.Р. и в качестве. написал бумагу.

Автор, ответственный за переписку

Переписка с Ананд Шривастава.

Заявление об этике

Конкурирующие интересы

Авторы не заявляют об отсутствии конкурирующих интересов.

Дополнительная информация

Информация о рецензировании Nature Communications благодарит Пола Робустелли и других анонимных рецензентов за их вклад в рецензирование этой работы. Доступны отчеты рецензентов.

Примечание издателя Springer Nature остается нейтральной в отношении юрисдикционных претензий в опубликованных картах и институциональной принадлежности.

Дополнительная информация

Файл рецензирования

РЕЗЮМЕ отчетности

Права и лицензии

, совместное использование, адаптацию, распространение и воспроизведение на любом носителе или в любом формате, при условии, что вы укажете первоначальных авторов и источник, предоставите ссылку на лицензию Creative Commons и укажете, были ли внесены изменения. Изображения или другие сторонние материалы в этой статье включены в лицензию Creative Commons для статьи, если иное не указано в кредитной строке материала. Если материал не включен в лицензию Creative Commons статьи, а ваше предполагаемое использование не разрешено законом или выходит за рамки разрешенного использования, вам необходимо получить разрешение непосредственно от правообладателя. Чтобы просмотреть копию этой лицензии, посетите http://creativecommons.org/licenses/by/4.0/.

Перепечатки и разрешения

Об этой статье

Отправляя комментарий, вы соглашаетесь соблюдать наши Условия и правила сообщества. Если вы обнаружите что-то оскорбительное или не соответствующее нашим условиям или правилам, отметьте это как неприемлемое.

Спецификация OpenAPI — Версия 3.0.3

Версия 3.0.3

Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ДОЛЖЕН», «НЕ ДОЛЖЕН» , «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документе следует интерпретировать, как описано в BCP 14 RFC2119.RFC8174, когда и только когда они появляются заглавными буквами, как показано здесь.

Этот документ находится под лицензией Apache License, Version 2.0.

Введение

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

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

Содержание

Определения
- Документ OpenAPI
- Шаблон пути
- Типы носителей
- Коды состояния HTTP
Спецификация
- Версии
- Формат
- Структура документа
- Типы данных
- Расширенное форматирование текста
- Относительные ссылки в URL-адресах
- Схема
  - Объект OpenAPI
  - Информационный объект
  - Контакт Объект
  - Объект лицензии
  - Объект сервера
  - Объект переменной сервера
  - Компоненты Объект
  - Пути Объект
  - Объект элемента пути
  - Операционный Объект
  - Объект внешней документации
  - Объект параметров
  - Объект тела запроса
  - Тип носителя Объект
  - Объект кодирования
  - Ответы Объект
  - Объект ответа
  - Объект обратного вызова
  - Пример объекта
  - Объект связи
  - Объект заголовка
  - Объект тега
  - Справочный объект
  - Объект схемы
  - Дискриминатор Объект
  - XML-объект
  - Объект схемы безопасности
  - Объект потоков OAuth
  - Объект потока OAuth
  - Объект требования безопасности
- Расширения спецификации
- Фильтрация безопасности
Приложение A: История изменений

Определения

Документ OpenAPI

Документ (или набор документов), определяющий или описывающий API. Определение OpenAPI использует спецификацию OpenAPI и соответствует ей.

Шаблон пути

Шаблон пути относится к использованию выражений шаблона, разделенных фигурными скобками ({}), для пометки раздела пути URL как заменяемого с использованием параметров пути.

Каждое выражение шаблона в пути ДОЛЖНО соответствовать параметру пути, который включен в сам элемент пути и/или в каждую из операций элемента пути.

Типы носителей

Определения типов носителей распределены по нескольким ресурсам. Определения типа носителя ДОЛЖНЫ соответствовать RFC6838.

Некоторые примеры возможных определений типа носителя:

 text/plain; кодировка = utf-8
  приложение/json
  приложение/vnd.github+json
  приложение/vnd.github.v3+json
  приложение/vnd.github.v3.raw+json
  приложение/vnd.github.v3.text+json
  приложение/vnd.github.v3.html+json
  приложение/vnd.github.v3.full+json
  приложение /vnd.github.v3.diff
  приложение /vnd.github.v3.patch

Коды состояния HTTP

Коды состояния HTTP используются для индикации состояния выполняемой операции. Доступные коды состояния определены в RFC7231, а зарегистрированные коды состояния перечислены в реестре кодов состояния IANA.

Спецификация

Версии

Версии спецификации OpenAPI создаются с использованием Semantic Versioning 2.0.0 (semver) и соответствуют спецификации semver.

Основной . второстепенная часть семвера (например 3.0 ) ДОЛЖЕН обозначать набор функций OAS. Как правило, в версиях .patch в этом документе рассматриваются ошибки, а не набор функций. Инструменты, поддерживающие OAS 3.0, ДОЛЖНЫ быть совместимы со всеми версиями OAS 3.0.*. Версия исправления НЕ ДОЛЖНА учитываться инструментами, например, не делая различий между 3.0.0 и 3.0.1 .

Каждая новая второстепенная версия Спецификации OpenAPI ДОЛЖНА позволять любому документу OpenAPI, который действителен по сравнению с любой предыдущей второстепенной версией Спецификации, в пределах той же основной версии быть обновленным до новой версии Спецификации с эквивалентной семантикой. Такое обновление ДОЛЖНО требовать только изменения свойство openapi для новой минорной версии.

Например, допустимый документ OpenAPI 3.0.2 после изменения свойства openapi на 3.1.0 ДОЛЖЕН быть действительным документом OpenAPI 3.1.0, семантически эквивалентным исходному документу OpenAPI 3.0.2. Новые второстепенные версии спецификации OpenAPI ДОЛЖНЫ быть написаны, чтобы обеспечить эту форму обратной совместимости.

Документ OpenAPI, совместимый с OAS 3.*.*, содержит обязательное поле openapi , которое обозначает используемую семантическую версию OAS. (Документы OAS 2.0 содержат поле версии верхнего уровня с именем swagger и значение "2.0" .)

Формат

Документ OpenAPI, соответствующий спецификации OpenAPI, сам по себе является объектом JSON, который может быть представлен в формате JSON или YAML.

Например, если поле имеет значение массива, будет использоваться представление массива JSON:

 {
   "поле": [ 1, 2, 3 ]
}

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

Схема предоставляет два типа полей: фиксированные поля с объявленным именем и шаблонные поля, которые объявляют шаблон регулярного выражения для имени поля.

Шаблонные поля ДОЛЖНЫ иметь уникальные имена в содержащем объекте.

Чтобы сохранить возможность переключения между форматами YAML и JSON, РЕКОМЕНДУЕТСЯ использовать YAML версии 1.2 вместе с некоторыми дополнительными ограничениями:

Теги ДОЛЖНЫ быть ограничены теми, которые разрешены набором правил схемы JSON.
Ключи, используемые в картах YAML, ДОЛЖНЫ быть ограничены скалярной строкой, как определено набором правил схемы YAML Failsafe.

Примечание: Хотя API могут быть определены документами OpenAPI в формате YAML или JSON, тела запросов и ответов API, а также другое содержимое не обязательно должны быть в формате JSON или YAML.

Структура документа

Документ OpenAPI МОЖЕТ состоять из одного документа или разделен на несколько связанных частей по усмотрению пользователя. В последнем случае Поля $ref ДОЛЖНЫ использоваться в спецификации для ссылки на эти части, как следует из определений схемы JSON.

РЕКОМЕНДУЕТСЯ, чтобы корневой документ OpenAPI имел имя: openapi.json или openapi.yaml .

Типы данных

Примитивные типы данных в OAS основаны на типах, поддерживаемых спецификацией схемы JSON Wright Draft 00. Обратите внимание, что целое число в качестве типа также поддерживается и определяется как число JSON без дробной или экспоненциальной части. null не поддерживается как тип (см. nullable для альтернативного решения). Модели определяются с помощью объекта схемы, который представляет собой расширенное подмножество спецификации схемы JSON Wright Draft 00.

Примитивы имеют необязательное свойство модификатора: формат . OAS использует несколько известных форматов для точного определения используемого типа данных. Однако для поддержки потребностей в документации свойство формата представляет собой открытую строку со значением и может иметь любое значение. Такие форматы, как "email" , "uuid" и т. д., МОГУТ использоваться, даже если они не определены этой спецификацией. Типы, которые не сопровождаются свойством формата , следуют определению типа в схеме JSON. Инструменты, которые не распознают определенный формат , МОГУТ по умолчанию вернуться к типу только , как если бы формат не был указан.

  OAS определяет следующие форматы: 
      тип  
 9формат 0574  
 Комментарии 
 
     целое число  
  инт32  
 32 бита со знаком 
    целое число  
  int64  
 подписанный 64-битный (длинный) 
    номер  
  поплавок  

    номер  
  двойной  

    струна  


    строка  
  байт  
 символов в кодировке base64 
    строка  
  двоичный  
 любая последовательность октетов 
    логический  


    строка  
  Дата  
 Как определено  полная дата  — RFC3339 
    строка  
  дата-время  
 Как определено  дата-время  — RFC3339 
    строка  
  пароль  
 Подсказка пользовательскому интерфейсу, чтобы скрыть ввод. 
 
 
  Расширенное форматирование текста 
  Во всей спецификации  описания  полей отмечены как поддерживающие форматирование уценки CommonMark.
Там, где инструментарий OpenAPI отображает форматированный текст, он ДОЛЖЕН поддерживать, как минимум, синтаксис уценки, как описано в CommonMark 0.27. Инструментарий МОЖЕТ игнорировать некоторые функции CommonMark для решения проблем безопасности. 
  Относительные ссылки в URL-адресах 
  Если не указано иное, все свойства, являющиеся URL-адресами, МОГУТ быть относительными ссылками, как определено в RFC3986.
Относительные ссылки разрешаются с использованием URL-адресов, определенных в объекте сервера   в качестве базового URI. 
  Относительные ссылки, используемые в  $ref , обрабатываются в соответствии со ссылкой JSON с использованием URL-адреса текущего документа в качестве базового URI. См. также Справочный объект. 
  Схема 
  В следующем описании, если поле не указано явно  ТРЕБУЕТСЯ  или описан как ДОЛЖЕН или СЛЕДУЕТ, его можно считать НЕОБЯЗАТЕЛЬНЫМ. 
  Объект OpenAPI 
  Это корневой объект документа OpenAPI. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    опенапи 
  струна  
  ТРЕБУЕТСЯ  . Эта строка ДОЛЖНА быть семантическим номером версии спецификации OpenAPI, которую использует документ OpenAPI. 9Поле 0574 openapi  СЛЕДУЕТ использовать спецификациям инструментов и клиентам для интерпретации документа OpenAPI. Это , а не , связанный со строкой API  info.version . 
   информация 
 Информационный объект 
  ТРЕБУЕТСЯ  . Предоставляет метаданные об API. Метаданные МОГУТ использоваться инструментами по мере необходимости. 
   серверов 
 [Объект сервера] 
 Массив серверных объектов, которые предоставляют информацию о подключении к целевому серверу. Если  серверы  свойство не указано или представляет собой пустой массив, значением по умолчанию будет объект сервера со значением URL-адреса / . 
   путей 
 Пути Объект 
  ТРЕБУЕТСЯ  . Доступные пути и операции для API. 
   компоненты 
 Компоненты Объект 
 Элемент для хранения различных схем спецификации. 
   безопасность 
 [Объект требования безопасности] 
 Объявление того, какие механизмы безопасности можно использовать в API. Список значений включает альтернативные объекты требований безопасности, которые можно использовать. Только один из объектов требования безопасности должен быть удовлетворен для авторизации запроса. Отдельные операции могут переопределить это определение. Чтобы сделать безопасность необязательной, в массив можно включить пустое требование безопасности (  {}  ). 
   теги 
 [Тег объекта] 
 Список тегов, используемых спецификацией, с дополнительными метаданными. Порядок тегов можно использовать для отражения их порядка инструментами синтаксического анализа. Не все теги, которые используются объектом операции, должны быть объявлены. Теги, которые не объявлены, МОГУТ быть организованы случайным образом или на основе логики инструментов. Каждое имя тега в списке ДОЛЖНО быть уникальным. 
   внешние документы 
 Объект внешней документации 
 Дополнительная внешняя документация. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Информационный объект 
  Объект предоставляет метаданные об API.
Метаданные МОГУТ использоваться клиентами при необходимости и МОГУТ быть представлены в инструментах редактирования или создания документации для удобства. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    название 
  струна  
  ТРЕБУЕТСЯ  . Название API. 
   описание 
  струна  
 Краткое описание API. Синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
   условия обслуживания 
  струна  
 URL-адрес условий обслуживания для API. ДОЛЖЕН быть в формате URL. 
   контакт 
 Контакт Объект 
 Контактная информация для открытого API. 
   лицензия 
 Объект лицензии 
 Информация о лицензии для открытого API. 
   версия 
  струна  
  ТРЕБУЕТСЯ  . Версия документа OpenAPI (отличная от версии спецификации OpenAPI или версии реализации API). 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Пример информационного объекта 
  {
  "title": "Пример приложения для зоомагазина",
  "description": "Это пример сервера для зоомагазина.",
  "termsOfService": "http://example.com/terms/",
  "контакт": {
    "name": "Поддержка API",
    "url": "http://www. example.com/support",
    "электронная почта": "[email protected]"
  },
  "лицензия": {
    "имя": "Апач 2.0",
    "url": "https://www.apache.org/licenses/LICENSE-2.0.html"
  },
  "версия": "1.0.1"
}
 
  title: Образец приложения для зоомагазина
описание: Это пример сервера для зоомагазина.
Условия обслуживания: http://example.com/terms/
контакт:
  имя: Поддержка API
  URL-адрес: http://www.example.com/support
  электронная почта: [email protected]
лицензия:
  имя: Апач 2.0
  URL-адрес: https://www.apache.org/licenses/LICENSE-2.0.html.
версия: 1.0.1
 
  Объект контакта 
  Контактная информация для открытого API. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    имя 
  струна  
 Идентификационное имя контактного лица/организации. 
   адрес 
  струна  
 URL-адрес, указывающий на контактную информацию. ДОЛЖЕН быть в формате URL. 
   электронная почта 
  струна  
 Адрес электронной почты контактного лица/организации. ДОЛЖЕН быть в формате адреса электронной почты. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Пример объекта контакта 
  {
  "name": "Поддержка API",
  "url": "http://www.example.com/support",
  "электронная почта": "[email protected]"
}
 
  имя: Поддержка API
URL-адрес: http://www.example.com/support
электронная почта: [email protected]
 
  Объект лицензии 
  Информация о лицензии для открытого API. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    имя 
  струна  
  ТРЕБУЕТСЯ  . Имя лицензии, используемое для API. 
   адрес 
  струна  
 URL-адрес лицензии, используемой для API. ДОЛЖЕН быть в формате URL. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Пример объекта лицензии 
  {
  "имя": "Апач 2.0",
  "url": "https://www.apache.org/licenses/LICENSE-2.0.html"
}
 
  имя: Apache 2.0
URL-адрес: https://www.apache.org/licenses/LICENSE-2.0.html.
 
  Объект сервера 
  Объект, представляющий сервер. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    адрес 
  струна  
  ТРЕБУЕТСЯ  . URL-адрес целевого хоста. Этот URL-адрес поддерживает серверные переменные и МОЖЕТ быть относительным, чтобы указать, что расположение хоста относится к местоположению, где обслуживается документ OpenAPI. Подстановки переменных будут сделаны, когда переменная названа в  {  скобки  }  . 
   описание 
  струна  
 Необязательная строка, описывающая хост, указанный URL-адресом. Синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
   переменные 
 Карта [ строка , объект переменной сервера] 
 Сопоставление между именем переменной и ее значением. Значение используется для подстановки в шаблоне URL-адреса сервера. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Пример объекта сервера 
  Отдельный сервер может быть описан как: 
  {
  "url": "https://development.gigantic-server.com/v1",
  "description": "Сервер разработки"
}
 
  URL-адрес: https://development.gigantic-server.com/v1
описание: Сервер разработки
 
  Ниже показано, как можно описать несколько серверов, например,  сервера объекта OpenAPI  : 
  {
  "серверы": [
    {
      "url": "https://development.gigantic-server.com/v1",
      "description": "Сервер разработки"
    },
    {
      "url": "https://staging. gigantic-server.com/v1",
      "description": "Промежуточный сервер"
    },
    {
      "url": "https://api.gigantic-server.com/v1",
      "description": "Производственный сервер"
    }
  ]
}
 
  серверов:
- URL-адрес: https://development.gigantic-server.com/v1
  описание: Сервер разработки
- URL-адрес: https://staging.gigantic-server.com/v1
  описание: Промежуточный сервер
- URL-адрес: https://api.gigantic-server.com/v1
  описание: Рабочий сервер
 
  Ниже показано, как можно использовать переменные для конфигурации сервера: 
  {
  "серверы": [
    {
      "url": "https://{имя пользователя}.gigantic-server.com:{порт}/{базовый путь}",
      "description": "Производственный сервер API",
      "переменные": {
        "имя пользователя": {
          "по умолчанию": "демо",
          "description": "это значение назначается поставщиком услуг, в данном примере это `gigantic-server.com`"
        },
        "порт": {
          "перечисление": [
            "8443",
            "443"
          ],
          "по умолчанию": "8443"
        },
        "базовый путь": {
          "по умолчанию": "v2"
        }
      }
    }
  ]
}
 
  серверов:
- URL-адрес: https://{имя пользователя}. gigantic-server.com:{порт}/{базовый путь}
  описание: Рабочий сервер API
  переменные:
    имя пользователя:
      # примечание! отсутствие перечисления здесь означает, что это открытое значение
      по умолчанию: демо
      описание: это значение назначается поставщиком услуг, в данном примере это `gigantic-server.com`.
    порт:
      перечисление:
        - '8443'
        - «443»
      по умолчанию: '8443'
    базовый путь:
      # открытый означает, что есть возможность использовать специальные базовые пути, назначенные провайдером, по умолчанию `v2`
      по умолчанию: v2
 
  Объект переменной сервера 
  Объект, представляющий переменную сервера для замены шаблона URL-адреса сервера. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    перечисление 
 [ строка ] 
 Перечисление строковых значений, которые следует использовать, если параметры подстановки относятся к ограниченному набору. Массив НЕ ДОЛЖЕН быть пустым. 
   по умолчанию 
  струна  
  ТРЕБУЕТСЯ  . Значение по умолчанию, используемое для замены, которое ДОЛЖНО быть отправлено, если предоставлено альтернативное значение , а не . Обратите внимание, что это поведение отличается от обработки Объектом схемы значений по умолчанию, потому что в этих случаях значения параметров являются необязательными. Если определено перечисление  , значение ДОЛЖНО существовать в значениях перечисления. 
   описание 
  струна  
 Необязательное описание серверной переменной. Синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Компоненты Объект 
  Содержит набор повторно используемых объектов для различных аспектов OAS.
Все объекты, определенные в объекте компонентов, не будут влиять на API, если на них явно не ссылаются свойства вне объекта компонентов. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    схемы 
 Карта[  строка  , Объект схемы | Справочный объект] 
 Объект для хранения повторно используемых объектов схемы. 
   ответов 
 Карта[  строка  , Объект ответа | Справочный объект] 
 Объект для хранения повторно используемых объектов ответа. 
   параметры 
 Карта[  строка  , объект параметра | Справочный объект] 
 Объект для хранения повторно используемых объектов параметров. 
   примеры 
 Карта[  строка  , пример объекта | Справочный объект] 
 Объект для хранения повторно используемых примеров объектов. 
   запросТело 
 Карта[  строка  , объект тела запроса | Справочный объект] 
 Объект для хранения повторно используемых объектов тела запроса. 
   коллекторы 
 Карта[  строка  , Объект заголовка | Справочный объект] 
 Объект для хранения повторно используемых объектов заголовка. 
   Схемы безопасности 
 Карта[  строка  , Объект схемы безопасности | Справочный объект] 
 Объект для хранения повторно используемых объектов схемы безопасности. 
   ссылки 
 Карта[  строка  , Объект ссылки | Справочный объект] 
 Объект для хранения многоразовых объектов Link. 
   обратные вызовы 
 Карта[  строка  , Объект обратного вызова | Справочный объект] 
 Объект для хранения повторно используемых объектов обратного вызова. 9[a-zA-Z0-9\.\-_]+$  . 
  Примеры имени поля: 
  Пользователь
Пользователь_1
Имя пользователя
имя пользователя
my.org.Пользователь
 
  Компоненты Пример объекта 
  "компоненты": {
  "схемы": {
    "Общая ошибка": {
      "тип": "объект",
      "характеристики": {
        "код": {
          "тип": "целое",
          "формат": "int32"
        },
        "сообщение": {
          "тип": "строка"
        }
      }
    },
    "Категория": {
      "тип": "объект",
      "характеристики": {
        "я бы": {
          "тип": "целое",
          "формат": "int64"
        },
        "имя": {
          "тип": "строка"
        }
      }
    },
    "Ярлык": {
      "тип": "объект",
      "характеристики": {
        "я бы": {
          "тип": "целое",
          "формат": "int64"
        },
        "имя": {
          "тип": "строка"
        }
      }
    }
  },
  "параметры": {
    "скиппарам": {
      "имя": "пропустить",
      "в": "запрос",
      "description": "количество элементов для пропуска",
      «требуется»: правда,
      "схема": {
        "тип": "целое",
        "формат": "int32"
      }
    },
    "лимитПарам": {
      "имя": "лимит",
      "в": "запрос",
      "description": "максимальное количество возвращаемых записей",
      «требуется»: правда,
      "схема": {
        "тип": "целое",
        "формат": "int32"
      }
    }
  },
  "ответы": {
    "Не обнаружена": {
      "description": "Объект не найден. "
    },
    "Незаконный ввод": {
      "description": "Недопустимый ввод для операции."
    },
    "Общая ошибка": {
      "description": "Общая ошибка",
      "содержание": {
        "приложение/json": {
          "схема": {
            "$ref": "#/компоненты/схемы/Общая ошибка"
          }
        }
      }
    }
  },
  "Схемы безопасности": {
    "апи_ключ": {
      "тип": "апиКей",
      "имя": "api_key",
      "в": "заголовок"
    },
    "зоомагазин_auth": {
      "тип": "oauth3",
      "течет": {
        "скрытый": {
          "authorizationUrl": "http://example.org/api/oauth/dialog",
          "области": {
            "write:pets": "изменить питомцев в вашем аккаунте",
            "read:pets": "читать своих питомцев"
          }
        }
      }
    }
  }
}
 
  компонентов:
  схемы:
    Общая ошибка:
      тип: объект
      характеристики:
        код:
          тип: целое число
          формат: int32
        сообщение:
          тип: строка
    Категория:
      тип: объект
      характеристики:
        я бы:
          тип: целое число
          формат: int64
        имя:
          тип: строка
    Ярлык:
      тип: объект
      характеристики:
        я бы:
          тип: целое число
          формат: int64
        имя:
          тип: строка
  параметры:
    пропуститьПарам:
      имя: пропустить
      в: запрос
      описание: количество элементов, которые нужно пропустить
      требуется: правда
      схема:
        тип: целое число
        формат: int32
    limitПарам:
      Название: лимит
      в: запрос
      описание: максимальное количество возвращаемых записей
      требуется: правда
      схема:
        тип: целое число
        формат: int32
  ответы:
    Не обнаружена:
      Описание: Объект не найден. 
    Незаконный ввод:
      Описание: Недопустимый ввод для операции.
    Общая ошибка:
      описание: Общая ошибка
      содержание:
        приложение/json:
          схема:
            $ref: '#/компоненты/схемы/Общая ошибка'
  схемы безопасности:
    ключ_апи:
      тип: апиКей
      имя: API_key
      в: заголовок
    зоомагазин_auth:
      тип: oauth3
      потоки:
        скрытый:
          URL-адрес авторизации: http://example.org/api/oauth/dialog
          области:
            write:pets: изменить питомцев в своей учетной записи
            read:pets: читай своих питомцев
 
  Paths Object 
  Содержит относительные пути к отдельным конечным точкам и их операциям.
Путь добавляется к URL-адресу из серверного объекта   для создания полного URL-адреса. Пути МОГУТ быть пустыми из-за ограничений ACL. 
  Узорчатые поля 
     Узорчатые поля 
 Тип 
 Описание 
 
    /{путь} 
 Объект элемента пути 
 Относительный путь к отдельной конечной точке. Имя поля ДОЛЖНО начинаться с косой черты ( /). Путь — это , добавленный  (без разрешения относительного URL-адреса) к расширенному URL-адресу из поля   URL-адреса  серверного объекта  для создания полного URL-адреса. Шаблоны путей разрешены. При сопоставлении URL-адресов конкретные (не шаблонные) пути будут сопоставляться перед их шаблонными аналогами. Шаблонные пути с одинаковой иерархией, но разными шаблонными именами НЕ ДОЛЖНЫ существовать, поскольку они идентичны. В случае неоднозначного сопоставления инструменты должны решить, какой из них использовать. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Сопоставление шаблонов путей 
  Предполагая следующие пути, конкретное определение  /pets/mine  будет сопоставляться первым, если используется: 
  /pets/{petId}
  /домашние животные/мой
 
  Следующие пути считаются идентичными и недействительными: 
  /pets/{petId}
  /имя питомца}
 
  Следующее может привести к неоднозначному разрешению: 
  /{entity}/me
  /книги/{id}
 
  Пример объекта путей 
  {
  "/домашние питомцы": {
    "получить": {
      "description": "Возвращает всех питомцев из системы, к которым у пользователя есть доступ",
      "ответы": {
        "200": {
          "description": "Список питомцев. ",
          "содержание": {
            "приложение/json": {
              "схема": {
                "тип": "массив",
                "Предметы": {
                  "$ref": "#/компоненты/схемы/животное"
                }
              }
            }
          }
        }
      }
    }
  }
}
 
  /домашние животные:
  получить:
    описание: Возвращает всех питомцев из системы, к которым у пользователя есть доступ
    ответы:
      «200»:
        описание: Список питомцев.
        содержание:
          приложение/json:
            схема:
              тип: массив
              Предметы:
                $ref: '#/компоненты/схемы/домашнее животное'
 
  Объект элемента пути 
  Описывает операции, доступные на одном пути.
Элемент пути МОЖЕТ быть пустым из-за ограничений ACL.
Сам путь по-прежнему открыт для просмотра документации, но они не будут знать, какие операции и параметры доступны. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    $ref 
  струна  
 Позволяет внешнее определение этого элемента пути. Структура, на которую делается ссылка, ДОЛЖНА быть в формате объекта элемента пути. В случае, если поле Объект элемента пути появляется как в определенном объекте, так и в объекте, на который указывает ссылка, поведение не определено. 
   резюме 
  струна  
 Необязательная строковая сводка, предназначенная для применения ко всем операциям в этом пути. 
   описание 
  струна  
 Необязательное строковое описание, предназначенное для применения ко всем операциям на этом пути. Синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
   получить 
 Операционный Объект 
 Определение операции GET на этом пути. 
   поставить 
 Операционный Объект 
 Определение операции PUT на этом пути. 
   пост 
 Операционный Объект 
 Определение операции POST на этом пути. 
   удалить 
 Операционный Объект 
 Определение операции DELETE на этом пути. 
   опции 
 Операционный Объект 
 Определение операции OPTIONS на этом пути. 
   головка 
 Операционный Объект 
 Определение операции HEAD на этом пути. 
   патч 
 Операционный Объект 
 Определение операции PATCH на этом пути. 
   след 
 Операционный Объект 
 Определение операции TRACE на этом пути. 
   серверов 
 [Объект сервера] 
 Альтернативный массив серверов   для обслуживания всех операций по этому пути. 
   параметры 
 [Объект параметров | Справочный объект] 
 Список параметров, применимых ко всем операциям, описанным в этом пути. Эти параметры можно переопределить на уровне операции, но нельзя удалить там. Список НЕ ДОЛЖЕН включать повторяющиеся параметры. Уникальный параметр определяется комбинацией имени и местоположения. Список может использовать ссылочный объект для связи с параметрами, которые определены в компонентах/параметрах объекта OpenAPI. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Пример объекта элемента пути 
  {
  "получить": {
    "description": "Возвращает питомцев по идентификатору",
    "summary": "Найти питомцев по ID",
    "operationId": "getPetsById",
    "ответы": {
      "200": {
        "description": "ответ питомца",
        "содержание": {
          "*/*": {
            "схема": {
              "тип": "массив",
              "Предметы": {
                "$ref": "#/компоненты/схемы/домашнее животное"
              }
            }
          }
        }
      },
      "дефолт": {
        "description": "полезная нагрузка ошибки",
        "содержание": {
          "текст/html": {
            "схема": {
              "$ref": "#/компоненты/схемы/ErrorModel"
            }
          }
        }
      }
    }
  },
  "параметры": [
    {
      "имя": "идентификатор",
      "в": "путь",
      "description": "ID питомца для использования",
      «требуется»: правда,
      "схема": {
        "тип": "массив",
        "Предметы": {
          "тип": "строка"
        }
      },
      "стиль": "простой"
    }
  ]
}
 
  получить:
  описание: Возвращает питомцев на основе ID
  резюме: Поиск домашних животных по идентификатору
  идентификатор операции: getPetsById
  ответы:
    «200»:
      описание: реакция питомца
      содержание:
        '*/*' :
          схема:
            тип: массив
            Предметы:
              $ref: '#/компоненты/схемы/домашнее животное'
    дефолт:
      описание: ошибка полезной нагрузки
      содержание:
        'текст/html':
          схема:
            $ref: '#/components/schemas/ErrorModel'
параметры:
- имя: идентификатор
  в: путь
  description: ID питомца для использования
  требуется: правда
  схема:
    тип: массив
    Предметы:
      тип: строка
  стиль: простой
 
  Operation Object 
  Описывает одну операцию API на пути. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    теги 
 [ строка ] 
 Список тегов для управления документацией API. Теги могут использоваться для логической группировки операций по ресурсам или любому другому классификатору. 
   резюме 
  струна  
 Краткое описание того, что делает операция. 
   описание 
  струна  
 Подробное объяснение поведения операции. Синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
   внешние документы 
 Объект внешней документации 
 Дополнительная внешняя документация для этой операции. 
   идентификатор операции 
  струна  
 Уникальная строка, используемая для идентификации операции. Идентификатор ДОЛЖЕН быть уникальным среди всех операций, описанных в API. Значение OperationId равно 9.3515 с учетом регистра  . Инструменты и библиотеки МОГУТ использовать идентификатор операции для уникальной идентификации операции, поэтому РЕКОМЕНДУЕТСЯ следовать общепринятым соглашениям об именах в программировании. 
   параметры 
 [Объект параметров | Справочный объект] 
 Список параметров, применимых для этой операции. Если параметр уже определен в элементе пути, новое определение переопределит его, но никогда не сможет удалить. Список НЕ ДОЛЖЕН включать повторяющиеся параметры. Уникальный параметр определяется комбинацией имени и местоположения. Список может использовать ссылочный объект для связи с параметрами, которые определены в компонентах/параметрах объекта OpenAPI. 
   запростело 
 Объект тела запроса | Справочный объект 
 Текст запроса, применимый для этой операции.  requestBody  поддерживается только в методах HTTP, где спецификация HTTP 1.1 RFC7231 явно определяет семантику для тела запроса. В других случаях, когда спецификация HTTP неопределенна, потребители ДОЛЖНЫ игнорировать  requestBody . 
   ответов 
 Ответы Объект 
  ТРЕБУЕТСЯ  . Список возможных ответов в том виде, в каком они возвращаются при выполнении этой операции. 
   обратные вызовы 
 Карта[  строка  , Объект обратного вызова | Справочный объект] 
 Карта возможных внеполосных обратных вызовов, связанных с родительской операцией. Ключ является уникальным идентификатором объекта обратного вызова. Каждое значение на карте — это объект обратного вызова, описывающий запрос, который может быть инициирован поставщиком API, и ожидаемые ответы. 
   устарело 
  логическое значение  
 Объявляет эту операцию устаревшей. Потребители ДОЛЖНЫ воздерживаться от использования объявленной операции. Значение по умолчанию:  false  . 
   безопасность 
 [Объект требования безопасности] 
 Объявление механизмов безопасности, которые можно использовать для этой операции. Список значений включает альтернативные объекты требований безопасности, которые можно использовать. Только один из объектов требования безопасности должен быть удовлетворен для авторизации запроса. Чтобы сделать безопасность необязательной, пустое требование безопасности (  {}  ) могут быть включены в массив. Это определение переопределяет любой объявленный уровень безопасности  верхнего уровня  . Чтобы удалить декларацию безопасности верхнего уровня, можно использовать пустой массив. 
   серверов 
 [Объект сервера] 
 Альтернативный серверный массив   для обслуживания этой операции. Если альтернативный объект  сервера  указан на уровне объекта элемента пути или корневого уровня, он будет переопределен этим значением. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Пример объекта операции 
  {
  "метки": [
    "домашний питомец"
  ],
  "summary": "Обновляет питомца в магазине с данными формы",
  "operationId": "updatePetWithForm",
  "параметры": [
    {
      "имя": "идентификатор домашнего животного",
      "в": "путь",
      "description": "ID питомца, который необходимо обновить",
      «требуется»: правда,
      "схема": {
        "тип": "строка"
      }
    }
  ],
  "тело запроса": {
    "содержание": {
      "приложение/x-www-форма-urlencoded": {
        "схема": {
          "тип": "объект",
          "характеристики": {
            "имя": {
              "description": "Обновлено имя питомца",
              "тип": "строка"
            },
            "статус": {
              "description": "Обновлен статус питомца",
              "тип": "строка"
            }
          },
          "требуется": ["статус"]
        }
      }
    }
  },
  "ответы": {
    "200": {
      "description": "Питомец обновлен. ",
      "содержание": {
        "приложение/json": {},
        "приложение/xml": {}
      }
    },
    "405": {
      "description": "Метод не разрешен",
      "содержание": {
        "приложение/json": {},
        "приложение/xml": {}
      }
    }
  },
  "безопасность": [
    {
      "зоомагазин_аутент": [
        "написать: домашние животные",
        "читать: домашние животные"
      ]
    }
  ]
}
 
  теги:
- домашний питомец
резюме: Обновляет питомца в магазине с данными формы
идентификатор операции: updatePetWithForm
параметры:
- имя: petId
  в: путь
  description: ID питомца, который нужно обновить
  требуется: правда
  схема:
    тип: строка
тело запроса:
  содержание:
    'приложение/x-www-form-urlencoded':
      схема:
       характеристики:
          имя:
            описание: Обновлено имя питомца
            тип: строка
          статус:
            описание: Обновлен статус питомца
            тип: строка
       требуется:
         - статус
ответы:
  «200»:
    описание: Питомец обновлен. 
    содержание:
      'приложение/json': {}
      'приложение/xml': {}
  «405»:
    описание: Метод не разрешен
    содержание:
      'приложение/json': {}
      'приложение/xml': {}
безопасность:
- petstore_auth:
  - напиши: домашние животные
  - читать: домашние животные
 
  Объект внешней документации 
  Позволяет ссылаться на внешний ресурс для получения расширенной документации. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    описание 
  струна  
 Краткое описание целевой документации. Синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
   адрес 
  строка  
  ТРЕБУЕТСЯ  . URL целевой документации. Значение ДОЛЖНО быть в формате URL. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Пример объекта внешней документации 
  {
  "description": "Подробнее здесь",
  "url": "https://example.com"
}
 
  описание: Подробнее здесь
адрес: https://example.com
 
  Объект параметра 
  Описывает один рабочий параметр. 
  Уникальный параметр определяется комбинацией имени и местоположения. 
  Расположение параметров 
  Существует четыре возможных расположения параметров, указанных в поле  в поле : 
   путь — используется вместе с шаблоном пути, где значение параметра фактически является частью URL-адреса операции. Это не включает хост или базовый путь API. Например, в  /items/{itemId}  параметр пути равен  itemId  . 
Запрос  — параметры, которые добавляются к URL-адресу. Например, в  /items?id=###  , параметр запроса  id  . 
Заголовок  — настраиваемые заголовки, которые ожидаются как часть запроса. Обратите внимание, что RFC7230 указывает, что имена заголовков нечувствительны к регистру. 
 cookie — используется для передачи определенного значения cookie в API. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    имя 
  струна  
  ТРЕБУЕТСЯ  . Имя параметра. Имена параметров  чувствительны к регистру  .   Если  в  является  "путем"  , поле  имени  ДОЛЖНО соответствовать выражению шаблона, встречающемуся в поле пути в объекте путей. Дополнительную информацию см. в разделе Шаблоны путей. 
  Если  в  — это  «заголовок» , а поле имени   — это  «Принять»  ,  «Content-Type»  или  «Авторизация» , определение параметра ДОЛЖНО игнорироваться. 
  Во всех остальных случаях имя   соответствует имени параметра, используемому свойством  в . 
 
 
   в 
  струна  
  ТРЕБУЕТСЯ  . Расположение параметра. Возможные значения:  "запрос"  ,  "заголовок"  ,  "путь"  или  "cookie"  . 
   описание 
  строка  
 Краткое описание параметра. Это может содержать примеры использования. Синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
   требуется 
  логическое значение  
 Определяет, является ли этот параметр обязательным. Если расположение параметра —  «путь»  , это свойство имеет значение  REQUIRED  и его значение ДОЛЖНО быть  true  . В противном случае свойство МОЖЕТ быть включено, и его значение по умолчанию равно  false  . 
   устарело 
  логическое значение  
 Указывает, что параметр устарел и его СЛЕДУЕТ вывести из использования. Значение по умолчанию:  false  . 
   разрешитьпустое значение 
  логическое значение  
 Устанавливает возможность передачи пустых параметров. Это справедливо только для  параметров запроса  и позволяет отправлять параметр с пустым значением. Значение по умолчанию:  false  . Если  используется стиль , и если поведение  н/д  (не может быть сериализовано), значение  allowEmptyValue  ДОЛЖНО игнорироваться. Использование этого свойства НЕ РЕКОМЕНДУЕТСЯ, так как оно может быть удалено в более поздних версиях. 
 
 
  Правила сериализации параметра задаются одним из двух способов.
Для более простых сценариев схема   и стиль   могут описывать структуру и синтаксис параметра. 
     Имя поля 
 Тип 
 Описание 
 
    стиль 
  струна  
 Описывает, как значение параметра будет сериализовано в зависимости от типа значения параметра. Значения по умолчанию (на основе значения  в  ): для запроса   -  форма  ; для  путь  -  простой  ; для заголовка   -  простой  ; для  куки  -  форма  . 
   взорвать 
  логическое значение  
 Когда это верно, значения параметров типа  массива  или  объекта  генерируют отдельные параметры для каждого значения массива или пары ключ-значение карты. Для других типов параметров это свойство не действует. Когда  стиль  равен  форме  , значением по умолчанию является  true  . Для всех остальных стилей значение по умолчанию —  false  . 
   разрешитьЗарезервировано 
  логическое значение  
 Определяет, СЛЕДУЕТ ли значение параметра разрешать включение зарезервированных символов, как определено в RFC3986  :/?#[]@!$&'()*+,;= , без процентного кодирования. Это свойство применяется только к параметрам со значением  в  запроса   . Значение по умолчанию —  false  . 
   схема 
 Объект схемы | Справочный объект 
 Схема, определяющая тип, используемый для параметра. 
   пример 
 Любой 
 Пример потенциального значения параметра. Пример ДОЛЖЕН соответствовать указанной схеме и свойствам кодирования, если они есть. Поле  примера  является взаимоисключающим полем  примеров . Кроме того, при ссылке на схему  , которая содержит пример, значение  примера  ДОЛЖНО  переопределять  пример, предоставленный схемой. Чтобы представить примеры типов мультимедиа, которые не могут быть представлены естественным образом в JSON или YAML, строковое значение может содержать пример с экранированием, где это необходимо. 
   примеры 
 Карта[  строка  , пример объекта | Справочный объект] 
 Примеры потенциального значения параметра. Каждый пример ДОЛЖЕН содержать значение в правильном формате, указанном в кодировке параметра. Поле  примеров  является взаимоисключающим полем  примеров . Кроме того, при ссылке на схему  , которая содержит пример, значение  примеров  ДОЛЖНО  переопределять  пример, предоставленный схемой. 
 
 
  Для более сложных сценариев свойство  content  может определять тип носителя и схему параметра.
Параметр ДОЛЖЕН содержать либо свойство  схемы , либо свойство  содержимого , но не то и другое одновременно.
Когда , пример  или , пример  предоставляется вместе с объектом схемы  , пример ДОЛЖЕН следовать предписанной стратегии сериализации для параметра. 
     Имя поля 
 Тип 
 Описание 
 
    содержание 
 Карта [ строка , объект типа мультимедиа] 
 Карта, содержащая представления параметра. Ключ — это тип носителя, а значение описывает его. Карта ДОЛЖНА содержать только одну запись. 
 
 
  Значения стиля 
  Для поддержки общих способов сериализации простых параметров определен набор значений  стиля . 
      стиль  
  тип  
  в  
 Комментарии 
 
    матрица 
  примитив  ,  массив  ,  объект  
  путь  
 Параметры стиля пути, определенные RFC6570 
   этикетка 
  примитив  ,  массив  ,  объект  
  путь  
 Параметры стиля метки, определенные RFC6570 
   форма 
  примитив  ,  массив  ,  объект  
  запрос  ,  файл cookie  
 Параметры стиля формы, определенные RFC6570. Этот параметр заменяет  collectionFormat  значением  csv  (когда  Explosion  имеет значение False) или  multi  (когда  Explosion  имеет значение true) из OpenAPI 2.0. 
   простой 
  массив  
  путь ,  заголовок  
 Параметры простого стиля, определенные RFC6570. Этот параметр заменяет  collectionFormat  значением  csv  из OpenAPI 2.0. 
   пробел 
  массив  
  запрос  
 Значения массива, разделенные пробелами. Этот параметр заменяет  collectionFormat  на  ssv  из OpenAPI 2.0. 
   труба с разделителями 
  массив  
  запрос  
 Значения массива, разделенные вертикальной чертой. Этот параметр заменяет  collectionFormat  равным  каналам  из OpenAPI 2. 0. 
   ГлубинныйОбъект 
  объект  
  запрос  
 Обеспечивает простой способ визуализации вложенных объектов с использованием параметров формы. 
 
 
  Примеры стилей 
  Предположим, что параметр с именем  цвет  имеет одно из следующих значений: 
  строка -> "синий"
   массив -> ["синий","черный","коричневый"]
   объект -> { "R": 100, "G": 200, "B": 150}
 
  В следующей таблице показаны примеры различий в отображении для каждого значения. 
      стиль  
  взорвать  
  пустой  
  струна  
  массив  
  объект  
 
    матрица 
 ложь 
 ;цвет 
 ;цвет=синий 
 ;цвет=синий,черный,коричневый 
 ;цвет=R,100,G,200,B,150 
   матрица 
 правда 
 ;цвет 
 ;цвет=синий 
 ;цвет=синий;цвет=черный;цвет=коричневый 
 ;R=100;G=200;B=150 
   этикетка 
 ложь 
 . 
 .синий 
 .синий.черный.коричневый 
 .R.100.G.200.B.150 
   этикетка 
 правда 
 . 
 .синий 
 .синий.черный.коричневый 
 .R=100.G=200.B=150 
   форма 
 ложь 
 цвет = 
 цвет=синий 
 цвет=синий,черный,коричневый 
 цвет=R,100,G,200,B,150 
   форма 
 правда 
 цвет = 
 цвет=синий 
 цвет=синий&цвет=черный&цвет=коричневый 
 R=100&G=200&B=150 
   простой 
 ложь 
 н/д 
 синий 
 синий, черный, коричневый 
 Р, 100, Г, 200, Б, 150 
   простой 
 правда 
 н/д 
 синий 
 синий, черный, коричневый 
 Р=100,Г=200,В=150 
   пробел 
 ложь 
 н/д 
 н/д 
 синий%20черный%20коричневый 
 Р%20100%20G%20200%20B%20150 
   труба с разделителями 
 ложь 
 н/д 
 н/д 
 синий|черный|коричневый 
 Р|100|Г|200|В|150 
   ГлубинныйОбъект 
 правда 
 н/д 
 н/д 
 н/д 
 цвет[R]=100&цвет[G]=200&цвет[B]=150 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Примеры объектов параметров 
  Параметр заголовка с массивом 64-битных целых чисел: 
  {
  "имя": "токен",
  "в": "заголовок",
  "description": "токен для передачи в качестве заголовка",
  «требуется»: правда,
  "схема": {
    "тип": "массив",
    "Предметы": {
      "тип": "целое",
      "формат": "int64"
    }
  },
  "стиль": "простой"
}
 
  имя: токен
в: заголовок
описание: токен для передачи в качестве заголовка
требуется: правда
схема:
  тип: массив
  Предметы:
    тип: целое число
    формат: int64
стиль: простой
 
  Параметр пути строкового значения: 
  {
  "имя": "имя пользователя",
  "в": "путь",
  "description": "имя пользователя для извлечения",
  «требуется»: правда,
  "схема": {
    "тип": "строка"
  }
}
 
  имя: имя пользователя
в: путь
описание: имя пользователя для получения
требуется: правда
схема:
  тип: строка
 
  Необязательный параметр запроса строкового значения, позволяющий использовать несколько значений путем повторения параметра запроса: 
  {
  "имя": "идентификатор",
  "в": "запрос",
  "description": "ID объекта для извлечения",
  «требуется»: ложь,
  "схема": {
    "тип": "массив",
    "Предметы": {
      "тип": "строка"
    }
  },
  "стиль": "форма",
  "взорваться": правда
}
 
  имя: идентификатор
в: запрос
описание: ID объекта для выборки
требуется: ложь
схема:
  тип: массив
  Предметы:
    тип: строка
стиль: форма
взорваться: правда
 
  Параметр запроса в произвольной форме, допускающий неопределенные параметры определенного типа: 
  {
  "в": "запрос",
  "имя": "свободная форма",
  "схема": {
    "тип": "объект",
    "дополнительные свойства": {
      "тип": "целое число"
    },
  },
  "стиль": "форма"
}
 
  в: запрос
Название: FreeForm
схема:
  тип: объект
  дополнительные свойства:
    тип: целое число
стиль: форма
 
  Сложный параметр, использующий содержимое   для определения сериализации: 
  {
  "в": "запрос",
  "имя": "координаты",
  "содержание": {
    "приложение/json": {
      "схема": {
        "тип": "объект",
        "требуется": [
          "лат",
          "длинная"
        ],
        "характеристики": {
          "лат": {
            "тип": "число"
          },
          "длинная": {
            "тип": "число"
          }
        }
      }
    }
  }
}
 
  в: запрос
имя: координаты
содержание:
  приложение/json:
    схема:
      тип: объект
      требуется:
        - лат
        - длинная
      характеристики:
        лат:
          тип: номер
        длинная:
          тип: номер
 
  Объект тела запроса 
  Описывает одно тело запроса. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    описание 
  строка  
 Краткое описание тела запроса. Это может содержать примеры использования. Синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
   содержание 
 Карта [ строка , объект типа мультимедиа] 
  ТРЕБУЕТСЯ  . Содержимое тела запроса. Ключ представляет собой тип носителя или диапазон типов носителя, а значение описывает его. Для запросов, соответствующих нескольким ключам, применим только самый конкретный ключ. например text/plain перекрывает текст/* 
   требуется 
  логическое значение  
 Определяет, требуется ли тело запроса в запросе. По умолчанию  false  . 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Примеры тела запроса 
  Тело запроса с определением модели, на которую ссылаются. 
  {
  "description": "пользователь для добавления в систему",
  "содержание": {
    "приложение/json": {
      "схема": {
        "$ref": "#/компоненты/схемы/пользователь"
      },
      "Примеры": {
          "пользователь" : {
            "summary": "Пример пользователя",
            "externalValue": "http://foo.bar/examples/user-example.json"
          }
        }
    },
    "приложение/xml": {
      "схема": {
        "$ref": "#/компоненты/схемы/пользователь"
      },
      "Примеры": {
          "пользователь" : {
            "summary": "Пример пользователя в XML",
            "externalValue": "http://foo.bar/examples/user-example.xml"
          }
        }
    },
    "текст/обычный": {
      "Примеры": {
        "пользователь" : {
            "summary": "Пример пользователя в текстовом формате",
            "externalValue": "http://foo.bar/examples/user-example.txt"
        }
      }
    },
    "*/*": {
      "Примеры": {
        "пользователь" : {
            "summary": "Пример пользователя в другом формате",
            "externalValue": "http://foo. bar/examples/user-example.whatever"
        }
      }
    }
  }
}
 
  описание: пользователь для добавления в систему
содержание:
  'приложение/json':
    схема:
      $ref: '#/компоненты/схемы/пользователь'
    Примеры:
      пользователь:
        резюме: пример пользователя
        externalValue: 'http://foo.bar/examples/user-example.json'
  'приложение/xml':
    схема:
      $ref: '#/компоненты/схемы/пользователь'
    Примеры:
      пользователь:
        резюме: Пример пользователя в XML
        externalValue: 'http://foo.bar/examples/user-example.xml'
  'текст/обычный':
    Примеры:
      пользователь:
        резюме: пример пользователя в текстовом формате
        externalValue: 'http://foo.bar/examples/user-example.txt'
  '*/*':
    Примеры:
      пользователь:
        резюме: пример пользователя в другом формате
        externalValue: 'http://foo.bar/examples/user-example.whatever'
 
  Основной параметр, представляющий собой массив строковых значений: 
  {
  "description": "пользователь для добавления в систему",
  "содержание": {
    "текст/обычный": {
      "схема": {
        "тип": "массив",
        "Предметы": {
          "тип": "строка"
        }
      }
    }
  }
}
 
  описание: пользователь для добавления в систему
требуется: правда
содержание:
  текст/обычный:
    схема:
      тип: массив
      Предметы:
        тип: строка
 
  Объект типа носителя 
  Каждый объект типа носителя предоставляет схему и примеры для типа носителя, определяемого его ключом. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    схема 
 Объект схемы | Справочный объект 
 Схема, определяющая содержимое запроса, ответа или параметра. 
   пример 
 Любой 
 Пример типа носителя. Образец объекта ДОЛЖЕН быть в правильном формате, указанном типом носителя. Поле примера   является взаимоисключающим полем 9.0574 примера  поле. Кроме того, при ссылке на схему  , которая содержит пример, значение  примера  ДОЛЖНО  переопределять пример , предоставленный схемой. 
   примеры 
 Карта[  строка  , пример объекта | Справочный объект] 
 Примеры типа носителя. Каждый пример объекта ДОЛЖЕН соответствовать типу носителя и указанной схеме, если она присутствует. Поле  примеров  является взаимоисключающим полем  пример  поле. Кроме того, при ссылке на схему  , которая содержит пример, значение  примеров  ДОЛЖНО  переопределять  пример, предоставленный схемой. 
   кодирование 
 Карта [ строка , объект кодирования] 
 Сопоставление между именем свойства и информацией о его кодировке. Ключ, являющийся именем свойства, ДОЛЖЕН существовать в схеме как свойство. Объект кодирования ДОЛЖЕН применяться только к  requestBody , когда тип мультимедиа  multipart  или  application/x-www-form-urlencoded  . 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Примеры типов носителей 
  {
  "приложение/json": {
    "схема": {
         "$ref": "#/компоненты/схемы/домашнее животное"
    },
    "Примеры": {
      "кошка" : {
        "summary": "Пример кота",
        "ценность":
          {
            "имя": "Пушистый",
            "petType": "Кошка",
            "белый цвет",
            "мужской пол",
            "порода": "персидская"
          }
      },
      "собака": {
        "summary": "Пример собаки с кошачьим именем",
        "ценность" :  {
          "имя": "Пума",
          "petType": "Собака",
          "черный цвет",
          "женский пол",
          "порода": "Смешанная"
        },
      "лягушка": {
          "$ref": "#/компоненты/примеры/пример-лягушки"
        }
      }
    }
  }
}
 
  приложение/json:
  схема:
    $ref: "#/компоненты/схемы/домашнее животное"
  Примеры:
    кошка:
      Резюме: Пример кота
      ценность:
        имя: Пушистый
        petType: Кошка
        белый цвет
        мужской пол
        порода: персидская
    собака:
      резюме: Пример собаки с кошачьим именем
      ценность:
        имя: Пума
        petType: Собака
        черный цвет
        женский пол
        порода: смешанная
    лягушка:
      $ref: "#/компоненты/примеры/пример-лягушки"
 
  Рекомендации по загрузке файлов 
  В отличие от спецификации 2. 0,  содержимое ввода/вывода файла  в OpenAPI описывается той же семантикой, что и любой другой тип схемы. В частности: 
  # контент, переданный с кодировкой base64
схема:
  тип: строка
  формат: base64
 
  # контент передается в двоичном виде (октетный поток):
схема:
  тип: строка
  формат: бинарный
 
  Эти примеры относятся либо к входным полезным нагрузкам загрузки файлов, либо к полезным нагрузкам ответа. 
   requestBody  для отправки файла в операции  POST  может выглядеть следующим образом: 
  requestBody:
  содержание:
    приложение/октетный поток:
      схема:
        # бинарный файл любого типа
        тип: строка
        формат: бинарный
 
  Кроме того, МОГУТ быть указаны определенные типы носителей: 
  # могут быть указаны несколько конкретных типов носителей:
тело запроса:
  содержание:
      # бинарный файл типа png или jpeg
    'изображение/jpeg':
      схема:
        тип: строка
        формат: бинарный
    'изображение/png':
      схема:
        тип: строка
        формат: бинарный
 
  Для загрузки нескольких файлов ДОЛЖЕН использоваться тип мультимедиа  multipart : 
  requestBody:
  содержание:
    составные/данные формы:
      схема:
        характеристики:
          # Имя свойства 'file' будет использоваться для всех файлов. 
          файл:
            тип: массив
            Предметы:
              тип: строка
              формат: бинарный
 
  Поддержка тела запроса x-www-form-urlencoded 
 
можно использовать определение: 
  тело запроса:
  содержание:
    приложение/x-www-форма-urlencoded:
      схема:
        тип: объект
        характеристики:
          я бы:
            тип: строка
            формат: UUID
          адрес:
            # сложные типы преобразуются в строки для поддержки RFC 1866
            тип: объект
            характеристики: {}
 
  В этом примере содержимое  requestBody  ДОЛЖНО быть преобразовано в строку в соответствии с RFC1866 при передаче на сервер. Кроме того, комплексный объект поля адреса   будет преобразован в строку. 
  При передаче сложных объектов в типе контента  application/x-www-form-urlencoded  стратегия сериализации таких свойств по умолчанию описана в свойстве  стиля  объекта кодирования   как  form  . 
  Особые соображения для 
 multipart  Content   Обычно используется  multipart/form-data  в качестве  Content-Type  при передаче тела запроса в операции. В отличие от 2.0, 9Схема 0574  ТРЕБУЕТСЯ для определения входных параметров операции при использовании многокомпонентного содержимого  . Это поддерживает сложные структуры, а также поддерживает механизмы для загрузки нескольких файлов. 
  При передаче типов  multipart  границы МОГУТ использоваться для разделения разделов передаваемого контента — таким образом, для  multipart  определены следующие значения по умолчанию  Content-Type  : 
   Если свойство является примитивом , или массив примитивных значений, Content-Type по умолчанию равен  текстовый/обычный  
 Если свойство является сложным или представляет собой массив сложных значений, Content-Type по умолчанию —  application/json  
 Если свойство имеет тип : строка  с форматом : двоичный формат  или формат : base64  (также известный как файловый объект), Content-Type по умолчанию —  application/octet-stream  
  Примеры: 
  requestBody:
  содержание:
    составные/данные формы:
      схема:
        тип: объект
        характеристики:
          я бы:
            тип: строка
            формат: UUID
          адрес:
            # Content-Type по умолчанию для объектов - `application/json`
            тип: объект
            характеристики: {}
          изображение профиля:
            # Content-Type по умолчанию для строки/двоичного файла: `application/octet-stream`
            тип: строка
            формат: бинарный
          дети:
            # Content-Type по умолчанию для массивов основан на `внутреннем` типе (здесь text/plain)
            тип: массив
            Предметы:
              тип: строка
          адреса:
            # Content-Type по умолчанию для массивов основан на `внутреннем` типе (показан объект, поэтому в этом примере `application/json`)
            тип: массив
            Предметы:
              тип: '#/компоненты/схемы/адрес'
 
  Атрибут кодирования   введен, чтобы дать вам возможность управлять сериализацией частей  составных тел запросов . Этот атрибут  только  применим к  multipart  и  application/x-www-form-urlencoded  тел запросов. 
  Объект кодирования 
  Одно определение кодирования, примененное к одному свойству схемы. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    тип содержимого 
  струна  
 Content-Type для кодирования определенного свойства. Значение по умолчанию зависит от типа свойства: для  строка  с форматом   является  бинарным  –  приложение/октет-поток  ; для остальных типов примитивов —  text/plain  ; для объекта   -  application/json  ; для массива   – значение по умолчанию определяется на основе внутреннего типа. Значение может быть конкретным типом носителя (например,  application/json  ), тип мультимедиа с подстановочными знаками (например,  image/*  ) или список двух типов, разделенных запятыми. 
   коллекторы 
 Карта[  строка  , Объект заголовка | Справочный объект] 
 Карта, позволяющая предоставлять дополнительную информацию в виде заголовков, например  Content-Disposition  .  Content-Type  описывается отдельно и ДОЛЖЕН быть проигнорирован в этом разделе. Это свойство ДОЛЖНО игнорироваться, если тип носителя тела запроса не является  составной  . 
   стиль 
  струна  
 Описывает, как определенное значение свойства будет сериализовано в зависимости от его типа. Подробнее о свойстве  стиля  см. в разделе Объект параметра. Поведение соответствует тем же значениям, что и параметры запроса  , включая значения по умолчанию. Это свойство ДОЛЖНО игнорироваться, если тип носителя тела запроса отличается от  application/x-www-form-urlencoded  . 
   взорвать 
  логическое значение  
 Когда это верно, значения свойства типа  массива  или  объекта  генерируют отдельные параметры для каждого значения массива или пары ключ-значение карты. Для других типов свойств это свойство не действует. Когда  стиль  равен  форме  , значением по умолчанию является  true  . Для всех остальных стилей значение по умолчанию —  false  . Это свойство ДОЛЖНО игнорироваться, если тип носителя тела запроса не равен 9.0574 приложение/x-www-form-urlencoded  . 
   разрешитьЗарезервировано 
  логическое значение  
 Определяет, СЛЕДУЕТ ли значение параметра разрешать включение зарезервированных символов, как определено в RFC3986  :/?#[]@!$&'()*+,;= , без процентного кодирования. Значение по умолчанию —  false  . Это свойство ДОЛЖНО игнорироваться, если тип носителя тела запроса отличается от  application/x-www-form-urlencoded  . 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Пример объекта кодирования 
  requestBody:
  содержание:
    составной/смешанный:
      схема:
        тип: объект
        характеристики:
          я бы:
            # по умолчанию текстовый/обычный
            тип: строка
            формат: UUID
          адрес:
            # по умолчанию это приложение/json
            тип: объект
            характеристики: {}
          историяМетаданные:
            # нужно объявить формат XML!
            описание: метаданные в формате XML
            тип: объект
            характеристики: {}
          изображение профиля:
            # по умолчанию используется application/octet-stream, необходимо объявить только тип изображения!
            тип: строка
            формат: бинарный
      кодировка:
        историяМетаданные:
          # требуется XML Content-Type в кодировке utf-8
          ContentType: приложение/xml; кодировка = utf-8
        изображение профиля:
          # принимаем только png/jpeg
          contentType: изображение/png, изображение/jpeg
          заголовки:
            X-Rate-Limit-Limit:
              описание: Количество разрешенных запросов в текущем периоде
              схема:
                тип: целое число
 
  Responses Object 
  Контейнер для ожидаемых ответов операции.
Контейнер сопоставляет код ответа HTTP с ожидаемым ответом. 
  Документация не обязательно должна охватывать все возможные коды ответов HTTP, поскольку они могут быть неизвестны заранее.
Однако ожидается, что документация будет охватывать успешный ответ операции и любые известные ошибки. 
   по умолчанию  МОЖЕТ использоваться в качестве объекта ответа по умолчанию для всех кодов HTTP
которые не рассматриваются отдельно в спецификации. 
  Объект ответов   ДОЛЖЕН содержать хотя бы один код ответа, и он
ДОЛЖЕН быть ответом на успешный вызов операции. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    по умолчанию 
 Объект ответа | Справочный объект 
 Документация ответов, отличных от заявленных для конкретных кодов ответов HTTP. Используйте это поле для покрытия необъявленных ответов. Справочный объект может ссылаться на ответ, который определяется в разделе компонентов/ответов объекта OpenAPI. 
 
 
  Узорчатые поля 
     Узорчатые поля 
 Тип 
 Описание 
 
    Код состояния HTTP 
 Объект ответа | Справочный объект 
 В качестве имени свойства можно использовать любой код состояния HTTP, но только одно свойство на код, чтобы описать ожидаемый ответ для этого кода состояния HTTP. Справочный объект может ссылаться на ответ, определенный в разделе компонентов/ответов объекта OpenAPI. Это поле ДОЛЖНО быть заключено в кавычки (например, «200») для совместимости между JSON и YAML. Чтобы определить диапазон кодов ответа, это поле МОЖЕТ содержать подстановочный знак 9 в верхнем регистре.0574 х  . Например,  2XX  представляет все коды ответа между  [200-299]  . Допускаются только следующие определения диапазона:  1XX  ,  2XX  ,  3XX  ,  4XX  и  5XX  . Если ответ определен с использованием явного кода, явное определение кода имеет приоритет над определением диапазона для этого кода. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Ответы Объект Пример 
  Ответ 200 для успешной операции и ответ по умолчанию для других (подразумевающий ошибку): 
  {
  "200": {
    "description": "животное, которое нужно вернуть",
    "содержание": {
      "приложение/json": {
        "схема": {
          "$ref": "#/компоненты/схемы/домашнее животное"
        }
      }
    }
  },
  "дефолт": {
    "description": "Непредвиденная ошибка",
    "содержание": {
      "приложение/json": {
        "схема": {
          "$ref": "#/компоненты/схемы/ErrorModel"
        }
      }
    }
  }
}
 
  '200':
  описание: домашнее животное, которое нужно вернуть
  содержание:
    приложение/json:
      схема:
        $ref: '#/компоненты/схемы/домашнее животное'
дефолт:
  описание: Непредвиденная ошибка
  содержание:
    приложение/json:
      схема:
        $ref: '#/components/schemas/ErrorModel'
 
  Response Object 
  Описывает один ответ от операции API, включая время разработки, статический
 связывает  с операциями на основе ответа. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    описание 
  струна  
  ТРЕБУЕТСЯ  . Краткое описание ответа. Синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
   коллекторы 
 Карта[  строка  , Объект заголовка | Справочный объект] 
 Сопоставляет имя заголовка с его определением. RFC7230 указывает, что имена заголовков нечувствительны к регистру. Если заголовок ответа определен с именем  "Content-Type"  , его ДОЛЖНО игнорировать. 
   содержание 
 Карта [ строка , объект типа мультимедиа] 
 Карта, содержащая описания потенциальных полезных данных ответа. Ключ представляет собой тип носителя или диапазон типов носителя, а значение описывает его. Для ответов, соответствующих нескольким ключам, применим только самый конкретный ключ. например text/plain переопределяет text/* 
   ссылки 
 Карта[  строка  , Объект ссылки | Справочный объект] 
 Карта ссылок операций, по которым можно перейти из ответа. Ключ карты — это короткое имя для ссылки, соответствующее ограничениям именования имен для объектов-компонентов. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Примеры объектов ответа 
  Ответ массива сложного типа: 
  {
  "description": "Ответ сложного массива объектов",
  "содержание": {
    "приложение/json": {
      "схема": {
        "тип": "массив",
        "Предметы": {
          "$ref": "#/компоненты/схемы/VeryComplexType"
        }
      }
    }
  }
}
 
  Описание: Ответ массива сложных объектов
содержание:
  приложение/json:
    схема:
      тип: массив
      Предметы:
        $ref: '#/компоненты/схемы/VeryComplexType'
 
  Ответ строкового типа: 
  {
  "description": "Простой строковый ответ",
  "содержание": {
    "текст/обычный": {
      "схема": {
        "тип": "строка"
      }
    }
  }
}
 
  описание: простой строковый ответ
содержание:
  текст/обычный:
    схема:
      тип: строка
 
  Простой текстовый ответ с заголовками: 
  {
  "description": "Простой строковый ответ",
  "содержание": {
    "текст/обычный": {
      "схема": {
        "тип": "строка",
        "пример": "вау!"
      }
    }
  },
  "заголовки": {
    "Ограничение скорости X-предела": {
      "description": "Количество разрешенных запросов в текущем периоде",
      "схема": {
        "тип": "целое число"
      }
    },
    "X-Rate-Limit-Remaining": {
      "description": "Количество оставшихся запросов в текущем периоде",
      "схема": {
        "тип": "целое число"
      }
    },
    "X-Rate-Limit-Reset": {
      "description": "Количество секунд, оставшихся до конца текущего периода",
      "схема": {
        "тип": "целое число"
      }
    }
  }
}
 
  описание: простой строковый ответ
содержание:
  текст/обычный:
    схема:
      тип: строка
    пример: "уоу!"
заголовки:
  X-Rate-Limit-Limit:
    описание: Количество разрешенных запросов в текущем периоде
    схема:
      тип: целое число
  X-Rate-Limit-Remaining:
    описание: количество оставшихся запросов в текущем периоде
    схема:
      тип: целое число
  X-Rate-Limit-Reset:
    описание: Количество секунд, оставшихся в текущем периоде
    схема:
      тип: целое число
 
  Ответ без возвращаемого значения: 
  {
  "description": "объект создан"
}
 
  описание: объект создан
 
  Объект обратного вызова 
  Карта возможных внеполосных обратных вызовов, связанных с родительской операцией.
Каждое значение на карте представляет собой объект элемента пути, описывающий набор запросов, которые могут быть инициированы поставщиком API, и ожидаемые ответы.
Ключевое значение, используемое для идентификации объекта элемента пути, представляет собой выражение, оцениваемое во время выполнения и идентифицирующее URL-адрес, используемый для операции обратного вызова. 
  Узорчатые поля 
     Узорчатые поля 
 Тип 
 Описание 
 
    {выражение} 
 Объект элемента пути 
 Объект элемента пути, используемый для определения запроса обратного вызова и ожидаемых ответов. Полный пример доступен. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Выражение ключа 
  Ключ, идентифицирующий объект элемента пути, представляет собой выражение времени выполнения, которое можно оценить в контексте HTTP-запроса/ответа времени выполнения для определения URL-адреса, который будет использоваться для запроса обратного вызова.
Простым примером может быть  $request.body#/url  .
Однако с помощью выражения времени выполнения можно получить доступ к полному сообщению HTTP.
Это включает в себя доступ к любой части тела, на которую может ссылаться указатель JSON RFC6901. 
  Например, для следующего HTTP-запроса: 
  POST /subscribe/myevent?queryUrl=http://clientdomain.com/stillrunning HTTP/1.1
Хост: example.org
Тип содержимого: приложение/json
Длина контента: 187
{
  "failedUrl": "http://clientdomain.com/failed",
  "URL-адреса успеха": [
    "http://clientdomain.com/fast",
    "http://clientdomain.com/medium",
    "http://clientdomain.com/slow"
  ]
}
201 Создано
Расположение: http://example.org/subscription/1.
 
  В следующих примерах показано, как оцениваются различные выражения, при условии, что операция обратного вызова имеет параметр пути с именем  eventType  и параметр запроса с именем  queryUrl  . 
     Выражение 
 Значение 
 
    URL-адрес 
 http://example. org/subscribe/myevent?queryUrl=http://clientdomain.com/stillrunning 
   $метод 
 ПОСТ 
   $request.path.eventType 
 мое событие 
   $request.query.queryUrl 
 http://clientdomain.com/stillrunning 
   $request.header.content-Type 
 приложение/json 
   $request.body#/failedUrl 
 http://clientdomain.com/failed 
   $request.body#/successUrls/2 
 http://clientdomain.com/medium 
   $response.header.Расположение 
 http://example.org/subscription/1 
 
 
  Примеры объектов обратного вызова 
  В следующем примере используется предоставленный пользователем параметр строки запроса  queryUrl  для определения URL-адреса обратного вызова. Это пример того, как использовать объект обратного вызова для описания обратного вызова WebHook, который идет с операцией подписки, чтобы включить регистрацию для WebHook. 
  мойОбратный звонок:
  '{$request.query.queryUrl}':
    почта:
      тело запроса:
        описание: Полезная нагрузка обратного вызова
        содержание:
          'приложение/json':
            схема:
              $ref: '#/компоненты/схемы/SomePayload'
      ответы:
        «200»:
          описание: обратный вызов успешно обработан
 
  В следующем примере показан обратный вызов, в котором сервер жестко запрограммирован, но параметры строки запроса заполняются из свойств  id  и  email  в тексте запроса. 
  транзакцияОбратный звонок:
  'http://notificationServer.com?transactionId={$request.body#/id}&email={$request.body#/email}':
    почта:
      тело запроса:
        описание: Полезная нагрузка обратного вызова
        содержание:
          'приложение/json':
            схема:
              $ref: '#/компоненты/схемы/SomePayload'
      ответы:
        «200»:
          описание: обратный вызов успешно обработан
 
  Пример объекта 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    резюме 
  струна  
 Краткое описание примера. 
   описание 
  струна  
 Подробное описание примера. Синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
   значение 
 Любой 
 Пример встроенного литерала. Поле значения   и поле  externalValue  являются взаимоисключающими. Чтобы представить примеры типов мультимедиа, которые не могут быть представлены естественным образом в JSON или YAML, используйте строковое значение, содержащее пример, с экранированием, где это необходимо. 
   внешнее значение 
  струна  
 URL-адрес, указывающий на буквальный пример. Это дает возможность ссылаться на примеры, которые нелегко включить в документы JSON или YAML. 9Поле значения 0574  и поле  externalValue  являются взаимоисключающими. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Во всех случаях ожидается, что значение примера будет совместимо со схемой типа
связанной с ним стоимости. Инструментальные реализации МОГУТ выбрать
автоматически проверять совместимость и отклонять примеры значений, если они несовместимы. 
  Пример Примеры объектов 
  В теле запроса: 
  запростело:
  содержание:
    'приложение/json':
      схема:
        $ref: '#/компоненты/схемы/адрес'
      Примеры:
        фу:
          резюме: пример foo
          значение: {"foo": "бар"}
        бар:
          резюме: пример бара
          значение: {"бар": "баз"}
    'приложение/xml':
      Примеры:
        xmlПример:
          резюме: это пример в XML
          externalValue: 'http://example.org/examples/address-example.xml'
    'текст/обычный':
      Примеры:
        текстПример:
          резюме: Это текстовый пример
          externalValue: 'http://foo.bar/examples/address-example.txt'
 
  В параметре: 
  параметры:
  - имя: 'zipCode'
    в: 'запрос'
    схема:
      тип: 'строка'
      формат: 'почтовый индекс'
    Примеры:
      zip-пример:
        $ref: '#/компоненты/примеры/zip-пример'
 
  В ответ: 
  ответов:
  «200»:
    описание: ваша автомобильная встреча была забронирована
    содержание:
      приложение/json:
        схема:
          $ref: '#/компоненты/схемы/SuccessResponse'
        Примеры:
          подтверждение-успех:
            $ref: '#/компоненты/примеры/подтверждение успеха'
 
  Link Object 
  Объект  Link  представляет собой возможную ссылку времени разработки для ответа.
Наличие ссылки не гарантирует, что вызывающая сторона сможет успешно вызвать ее, а скорее обеспечивает известную взаимосвязь и механизм обхода между ответами и другими операциями. 
  В отличие от  динамических  ссылок (т. е. ссылок, предоставленных  в полезной нагрузке ответа), механизм связывания OAS не требует информации о ссылке в ответе во время выполнения. 
  Для вычисления ссылок и предоставления инструкций по их выполнению выражение времени выполнения используется для доступа к значениям в операции и использования их в качестве параметров при вызове связанной операции. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    эксплуатацияRef 
  струна  
 Относительная или абсолютная ссылка URI на операцию OAS. Это поле является взаимоисключающим из  operationId  и ДОЛЖЕН указывать на объект операции. Относительные  значения operationRef  МОГУТ использоваться для обнаружения существующего объекта операции в определении OpenAPI. 
   идентификатор операции 
  струна  
 Имя  существующей  разрешимой операции OAS, определенной с помощью уникального  идентификатора операции  . Это поле является взаимоисключающим полем  operationRef . 
   параметры 
 Карта[  строка  , Любая | {выражение}] 
 Карта, представляющая параметры для передачи в операцию, указанную с помощью  operationId  или идентифицированную с помощью  operationRef  . Ключ — это имя используемого параметра, тогда как значение может быть константой или выражением, которое нужно вычислить и передать в связанную операцию. Имя параметра можно уточнить, используя расположение параметра  [{in}.]{name}  для операций, использующих одно и то же имя параметра в разных местах (например, path.id). 
   запростело 
 Любой | {выражение} 
 Буквенное значение или {выражение} для использования в качестве тела запроса при вызове целевой операции. 
   описание 
  струна  
 Описание ссылки. Синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
   сервер 
 Объект сервера 
 Объект сервера, который будет использоваться целевой операцией. 
 
 
  Этот объект МОЖЕТ быть расширен с помощью расширений спецификаций. 
  Связанная операция ДОЛЖНА быть идентифицирована с помощью  operationRef  или  operationId  .
В случае  operationId  он ДОЛЖЕН быть уникальным и разрешаться в рамках документа OAS.
Из-за возможного конфликта имен предпочтительным является синтаксис  operationRef .
для спецификаций с внешними ссылками. 
  Примеры 
  Вычисление ссылки из операции запроса, где  $request.path.id  используется для передачи параметра запроса связанной операции. 
  путей:
  /пользователи/{идентификатор}:
    параметры:
    - имя: идентификатор
      в: путь
      требуется: правда
      описание: идентификатор пользователя, как userId
      схема:
        тип: строка
    получить:
      ответы:
        «200»:
          описание: возвращаемый пользователь
          содержание:
            приложение/json:
              схема:
                тип: объект
                характеристики:
                  uuid: # уникальный идентификатор пользователя
                    тип: строка
                    формат: UUID
          ссылки:
            адрес:
              # идентификатор операции целевой ссылки
              идентификатор операции: getUserAddress
              параметры:
                # получить поле `id` из параметра пути запроса с именем `id`
                идентификатор пользователя: $ request. path.id
  # элемент пути связанной операции
  /users/{идентификатор пользователя}/адрес:
    параметры:
    - имя: идентификатор пользователя
      в: путь
      требуется: правда
      описание: идентификатор пользователя, как userId
      схема:
        тип: строка
    # связанная операция
    получить:
      идентификатор операции: getUserAddress
      ответы:
        «200»:
          описание: адрес пользователя
 
  Если выражение среды выполнения не может быть оценено, в целевую операцию не передается значение параметра. 
  Значения из тела ответа можно использовать для управления связанной операцией. 
  ссылки:
  адрес:
    идентификатор операции: getUserAddressByUUID
    параметры:
      # получить поле `uuid` из поля `uuid` в теле ответа
      userUuid: $response.body#/uuid
 
  Клиенты переходят по всем ссылкам на свое усмотрение.
Ни разрешения, ни возможность сделать успешный вызов по этой ссылке не гарантируются.
исключительно наличием отношений. 
  OperationRef Примеры 
  Поскольку ссылки на  operationId  МОГУТ быть НЕвозможными ( operationId  является необязательным
поле в объекте операции), ссылки МОГУТ также быть сделаны через относительные ссылки  operationRef  : 
 :
  Пользовательские репозитории:
    # возвращает массив '#/components/schemas/repository'
    OperationRef: '#/paths/~12. 0~1repositories~1{username}/get'
    параметры:
      имя пользователя: $response.body#/имя пользователя
 
  или абсолютная  OperationRef  : 
  ссылки:
  Пользовательские репозитории:
    # возвращает массив '#/components/schemas/repository'
    OperationRef: 'https://na2.gigantic-server.com/#/paths/~12.0~1repositories~1{username}/get'
    параметры:
      имя пользователя: $response.body#/имя пользователя
 
  Обратите внимание, что при использовании  operationRef  экранированная косая черта   необходима, когда
используя ссылки JSON. 
  Выражения среды выполнения 
  Выражения среды выполнения позволяют определять значения на основе информации, которая будет доступна только в HTTP-сообщении при фактическом вызове API.
Этот механизм используется объектами Link и Callback Objects. 
  Выражение среды выполнения определяется следующим синтаксисом ABNF: 
  выражение = ("$url" / "$method" / "$statusCode" / "$request. " / "_" / "`" / "|" / "~" / ЦИФРА / АЛЬФА
 
  Здесь  json-pointer  взят из RFC 6901,  char  из RFC 7159 и  токен  из RFC 7230. 
  В таблице ниже приведены примеры выражений времени выполнения и примеры их использования в значении: 
  Примеры 
     Исходное местоположение 
 пример выражения 
 отмечает 
 
    Метод HTTP 
  $метод  
 Допустимые значения для  $method  будут такими же, как и для операции HTTP. 
   Запрошенный тип носителя 
  $request.header.accept  

   Параметр запроса 
  $request.path.id  
 Параметры запроса ДОЛЖНЫ быть объявлены в разделе  параметров  родительской операции, иначе они не могут быть оценены. Сюда входят заголовки запросов. 
   Свойство тела запроса 
  $request. body#/пользователь/uuid  
 В операциях, которые принимают полезные нагрузки, могут быть сделаны ссылки на части  requestBody  или все тело. 
   URL запроса 
  URL-адрес  

   Значение ответа 
  $response.body#/статус  
 В операциях, которые возвращают полезные данные, могут быть сделаны ссылки на части тела ответа или на все тело. 
   Заголовок ответа 
  $response.header.Сервер  
 Доступны только отдельные значения заголовка 
 
 
  Выражения среды выполнения сохраняют тип значения, на которое указывает ссылка.
Выражения можно встраивать в строковые значения, окружая выражение фигурными скобками  {} . 
  Объект заголовка повторяет структуру объекта параметров со следующими изменениями: 
    имя НЕ ДОЛЖНО указываться, оно указывается в соответствующем  заголовки  карта. 

  в  НЕ ДОЛЖНО быть указано, это неявно в заголовке   . 
 Все признаки, на которые влияет местоположение, ДОЛЖНЫ быть применимы к местоположению  заголовка  (например,  стиль ). 
  Простой заголовок типа  целое число  : 
  {
  "description": "Количество разрешенных запросов в текущем периоде",
  "схема": {
    "тип": "целое число"
  }
}
 
 Описание : количество разрешенных запросов в текущем периоде
схема:
  тип: целое число
 
  Объект тега 
  Добавляет метаданные к одному тегу, используемому объектом операции.
Не обязательно иметь объект тега для каждого тега, определенного в экземплярах объекта операции. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    имя 
  струна  
  ТРЕБУЕТСЯ  . Имя тега. 
   описание 
  струна  
 Краткое описание тега. Синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
   внешние документы 
 Объект внешней документации 
 Дополнительная внешняя документация для этого тега. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Пример объекта тега 
  {
"имя": "домашнее животное",
"description": "Операции с домашними животными"
}
 
  имя: домашнее животное
описание: Операции с домашними животными
 
  Объект ссылки 
  Простой объект, позволяющий ссылаться на другие компоненты в спецификации, как внутри, так и снаружи. 
  Объект ссылки определяется ссылкой JSON и следует той же структуре, поведению и правилам. 
  Для этой спецификации разрешение ссылки выполняется в соответствии со спецификацией JSON Reference, а не спецификацией JSON Schema. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    $ref 
  струна  
  ТРЕБУЕТСЯ  . Ссылочная строка. 
 
 
  Этот объект не может быть расширен дополнительными свойствами, и любые добавленные свойства ДОЛЖНЫ игнорироваться. 
  Пример ссылочного объекта 
  {
"$ref": "#/компоненты/схемы/домашнее животное"
}
 
  $ref: '#/components/schemas/Pet'
 
  Пример документа относительной схемы 
  {
  "$ref": "Pet.json"
}
 
  $ref: Pet.yaml
 
  Родственные документы со встроенной схемой Пример 
  {
  "$ref": "definitions.json#/домашнее животное"
}
 
  $ref: определения.yaml#/домашнее животное
 
  Объект схемы 
  Объект схемы позволяет определять типы входных и выходных данных.
Эти типы могут быть объектами, а также примитивами и массивами.
Этот объект является расширенным подмножеством спецификации схемы JSON Wright Draft 00. 
  Дополнительные сведения о свойствах см. в разделе Ядро схемы JSON и Проверка схемы JSON.
Если не указано иное, определения свойств следуют схеме JSON. 
  Свойства 
  Следующие свойства взяты непосредственно из определения схемы JSON и соответствуют тем же спецификациям: 
   title 
 кратно 
 максимум 
 эксклюзивМаксимум 
 минимум 
 эксклюзивМинимум 
 максимальная длина 
 минДлина 
Шаблон  (Эта строка ДОЛЖНА быть допустимым регулярным выражением в соответствии с диалектом регулярных выражений Ecma-262 Edition 5.1) 
 Максимальное количество элементов 
 минЭлементов 
 уникальных предметов 
 МаксСвойства 
 минСвойства 
 требуется 
 перечисление 
  Следующие свойства взяты из определения схемы JSON, но их определения были скорректированы в соответствии со спецификацией OpenAPI. 
   тип — значение ДОЛЖНО быть строкой. Несколько типов через массив не поддерживаются. 
 allOf — встроенная или ссылочная схема ДОЛЖНА быть объектом схемы, а не стандартной схемой JSON. 
 oneOf — встроенная или ссылочная схема ДОЛЖНА быть объектом схемы, а не стандартной схемой JSON. 
 anyOf — встроенная или ссылочная схема ДОЛЖНА быть объектом схемы, а не стандартной схемой JSON. 
 нет — встроенная или ссылочная схема ДОЛЖНА быть объектом схемы, а не стандартной схемой JSON. 
 элементов — значение ДОЛЖНО быть объектом, а не массивом. Встроенная или ссылочная схема ДОЛЖНА быть объектом схемы, а не стандартной схемой JSON.  шт.  ДОЛЖЕН присутствовать, если  тип  - это массив   . 
Свойства . Определения свойств ДОЛЖНЫ быть объектом схемы, а не стандартной схемой JSON (встроенной или указанной). 
 AdditionalProperties — значение может быть логическим или объектным. Встроенная или ссылочная схема ДОЛЖНА быть объектом схемы, а не стандартной схемой JSON. В соответствии со схемой JSON,  AdditionalProperties  по умолчанию имеет значение  true  . 
Описание  — синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
Формат  — дополнительные сведения см. в разделе «Форматы типов данных». Опираясь на определенные форматы схемы JSON, OAS предлагает несколько дополнительных предопределенных форматов. 
 по умолчанию — значение по умолчанию представляет собой то, что потребитель входных данных принял бы за значение схемы, если оно не указано. В отличие от схемы JSON, значение ДОЛЖНО соответствовать определенному типу для объекта схемы, определенного на том же уровне. Например, если  тип  является  строкой  , то  по умолчанию  может быть  "foo" , но не может быть  1  . 
  В качестве альтернативы, каждый раз, когда можно использовать объект схемы, вместо него можно использовать объект ссылки. Это позволяет ссылаться на определения вместо их встроенного определения. 
  Дополнительные свойства, определенные спецификацией схемы JSON и не упомянутые здесь, строго не поддерживаются. 
  Помимо полей подмножества схемы JSON, следующие поля МОГУТ использоваться для дальнейшей документации схемы: 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    Обнуляемый 
  логическое значение  
 Значение  true  добавляет  "null"  к разрешенному типу, заданному ключевым словом  type , только если тип   явно определен в том же объекте схемы. Другие ограничения объекта схемы сохраняют свое определенное поведение и, следовательно, могут запрещать использование  null  в качестве значения. Значение  false  оставляет указанный или заданный по умолчанию тип  без изменений. Значение по умолчанию —  false  . 
   дискриминатор 
 Дискриминатор Объект 
 Добавляет поддержку полиморфизма. Дискриминатор — это имя объекта, которое используется для различения других схем, которые могут удовлетворять описанию полезной нагрузки. Дополнительные сведения см. в разделе Композиция и наследование. 
   Только для чтения 
  логическое значение  
 Относится только к определениям схемы  "свойства" . Объявляет свойство как «только для чтения». Это означает, что он МОЖЕТ быть отправлен как часть ответа, но НЕ ДОЛЖЕН быть отправлен как часть запроса. Если свойство помечено как  readOnly , являющееся  true  и находится в списке  required , то  required  повлияет только на ответ. Свойство НЕ ДОЛЖНО быть помечено как  только для чтения  и  writeOnly  равно  true  . Значение по умолчанию:  false  . 
   только запись 
  логическое значение  
 Относится только к определениям схемы  "свойства" . Объявляет свойство как «только для записи». Следовательно, он МОЖЕТ быть отправлен как часть запроса, но НЕ ДОЛЖЕН быть отправлен как часть ответа. Если свойство помечено как  writeOnly , являющееся  истинным  и находится в списке обязательных  , то  требуется  вступит в силу только по запросу. Свойство НЕ ДОЛЖНО быть помечено как  readOnly  и  writeOnly , являющееся  true  . Значение по умолчанию:  false  . 
   XML-файл 
 XML-объект 
 МОЖЕТ использоваться только в схемах свойств. Это не влияет на корневые схемы. Добавляет дополнительные метаданные для описания XML-представления этого свойства. 
   внешние документы 
 Объект внешней документации 
 Дополнительная внешняя документация для этой схемы. 
   пример 
 Любой 
 Свойство в произвольной форме для включения примера экземпляра для этой схемы. Чтобы представить примеры, которые не могут быть представлены естественным образом в JSON или YAML, можно использовать строковое значение, содержащее пример с экранированием, где это необходимо. 
   устарело 
  логическое значение  
 Указывает, что схема устарела и ее СЛЕДУЕТ вывести из использования. Значение по умолчанию – 9.0574 ложь  . 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Композиция и наследование (полиморфизм) 
  Спецификация OpenAPI позволяет комбинировать и расширять определения моделей, используя свойство  allOf  схемы JSON, фактически предлагая композицию модели.
 allOf  принимает массив определений объектов, которые проверены  независимо  , но вместе составляют единый объект. 
  Хотя композиция обеспечивает расширяемость модели, она не предполагает иерархии между моделями.
Для поддержки полиморфизма спецификация OpenAPI добавляет  дискриминатор  поле.
При использовании дискриминатор   будет именем свойства, которое решает, какое определение схемы проверяет структуру модели.
Таким образом, поле  дискриминатора  ДОЛЖНО быть обязательным полем.
Есть два способа определить значение дискриминатора для наследуемого экземпляра. 
   Используйте имя схемы. 
 Переопределить имя схемы, заменив свойство новым значением. Если существует новое значение, оно имеет приоритет над именем схемы.
Таким образом, встроенные определения схемы, которые не имеют заданного идентификатора,  не может  использоваться в полиморфизме. 
  Моделирование XML 
  Свойство xml позволяет использовать дополнительные определения при преобразовании определения JSON в XML.
Объект XML содержит дополнительную информацию о доступных параметрах. 
  Примеры объектов схемы 
  Образец примитива 
  {
  "тип": "строка",
  "формат": "электронная почта"
}
 
  тип: строка
формат: электронная почта
 
  Простая модель 
  {
  "тип": "объект",
  "требуется": [
    "имя"
  ],
  "характеристики": {
    "имя": {
      "тип": "строка"
    },
    "адрес": {
      "$ref": "#/компоненты/схемы/адрес"
    },
    "возраст": {
      "тип": "целое",
      "формат": "int32",
      "минимум": 0
    }
  }
}
 
  тип: объект
требуется:
- имя
характеристики:
  имя:
    тип: строка
  адрес:
    $ref: '#/компоненты/схемы/адрес'
  возраст:
    тип: целое число
    формат: int32
    минимум: 0
 
  Модель со свойствами карты/словаря 
  Для простого преобразования строки в строку: 
  {
  "тип": "объект",
  "дополнительные свойства": {
    "тип": "строка"
  }
}
 
  тип: объект
дополнительные свойства:
  тип: строка
 
  Для сопоставления строки с моделью: 
  {
  "тип": "объект",
  "дополнительные свойства": {
    "$ref": "#/компоненты/схемы/ComplexModel"
  }
}
 
  тип: объект
дополнительные свойства:
  $ref: '#/компоненты/схемы/ComplexModel'
 
  Модель с примером 
  {
  "тип": "объект",
  "характеристики": {
    "я бы": {
      "тип": "целое",
      "формат": "int64"
    },
    "имя": {
      "тип": "строка"
    }
  },
  "требуется": [
    "имя"
  ],
  "пример": {
    "имя": "Пума",
    "идентификатор": 1
  }
}
 
  тип: объект
характеристики:
  я бы:
    тип: целое число
    формат: int64
  имя:
    тип: строка
требуется:
- имя
пример:
  имя: Пума
  идентификатор: 1
 
  Модели с составом 
  {
  "составные части": {
    "схемы": {
      "Модель ошибки": {
        "тип": "объект",
        "требуется": [
          "сообщение",
          "код"
        ],
        "характеристики": {
          "сообщение": {
            "тип": "строка"
          },
          "код": {
            "тип": "целое",
            "минимум": 100,
            "максимум": 600
          }
        }
      },
      "ExtendedErrorModel": {
        "все": [
          {
            "$ref": "#/компоненты/схемы/ErrorModel"
          },
          {
            "тип": "объект",
            "требуется": [
              "первопричина"
            ],
            "характеристики": {
              "первопричина": {
                "тип": "строка"
              }
            }
          }
        ]
      }
    }
  }
}
 
  компонентов:
  схемы:
    Модель ошибки:
      тип: объект
      требуется:
      - сообщение
      - код
      характеристики:
        сообщение:
          тип: строка
        код:
          тип: целое число
          минимум: 100
          максимум: 600
    Расширенная модель ошибки:
      все:
      - $ref: '#/components/schemas/ErrorModel'
      - тип: объект
        требуется:
        - первопричина
        характеристики:
          первопричина:
            тип: строка
 
  Модели с поддержкой полиморфизма 
  {
  "составные части": {
    "схемы": {
      "Домашний питомец": {
        "тип": "объект",
        "дискриминатор": {
          "имя_свойства": "тип_питомца"
        },
        "характеристики": {
          "имя": {
            "тип": "строка"
          },
          "тип питомца": {
            "тип": "строка"
          }
        },
        "требуется": [
          "имя",
          "тип питомца"
        ]
      },
      "Кошка": {
        "description": "Изображение кошки.  Обратите внимание, что `Cat` будет использоваться в качестве значения дискриминатора.",
        "все": [
          {
            "$ref": "#/компоненты/схемы/домашнее животное"
          },
          {
            "тип": "объект",
            "характеристики": {
              "охотничий навык": {
                "тип": "строка",
                "description": "Измеренное умение для охоты",
                "по умолчанию": "ленивый",
                "перечисление": [
                  "невежественный",
                  "ленивый",
                  "авантюрный",
                  "агрессивный"
                ]
              }
            },
            "требуется": [
              "охотничий навык"
            ]
          }
        ]
      },
      "Собака": {
        "description": "Изображение собаки. Обратите внимание, что `Dog` будет использоваться в качестве значения дискриминатора.",
        "все": [
          {
            "$ref": "#/компоненты/схемы/домашнее животное"
          },
          {
            "тип": "объект",
            "характеристики": {
              "packSize": {
                "тип": "целое",
                "формат": "int32",
                "description": "размер стаи, из которой собака",
                "по умолчанию": 0,
                "минимум": 0
              }
            },
            "требуется": [
              "Размер упаковки"
            ]
          }
        ]
      }
    }
  }
}
 
  компонентов:
  схемы:
    Домашний питомец:
      тип: объект
      дискриминатор:
        имя свойства: petType
      характеристики:
        имя:
          тип: строка
        тип питомца:
          тип: строка
      требуется:
      - имя
      - тип питомца
    Cat: ## "Cat" будет использоваться как значение дискриминатора
      описание: Представление кота
      все:
      - $ref: '#/components/schemas/Pet'
      - тип: объект
        характеристики:
          охотничий навык:
            тип: строка
            описание: Измеренное умение для охоты
            перечисление:
            - невежественный
            - ленивый
            - предприимчивый
            - агрессивный
        требуется:
        - охотничье мастерство
    Собака: ## «Собака» будет использоваться в качестве значения дискриминатора. 
      описание: изображение собаки
      все:
      - $ref: '#/components/schemas/Pet'
      - тип: объект
        характеристики:
          размер пакета:
            тип: целое число
            формат: int32
            описание: размер стаи, из которой собака
            по умолчанию: 0
            минимум: 0
        требуется:
        - размер упаковки
 
  Объект-дискриминатор 
  Если тело запроса или полезная нагрузка ответа могут быть одной из нескольких различных схем, можно использовать объект-дискриминатор   для облегчения сериализации, десериализации и проверки. Дискриминатор — это особый объект в схеме, который используется для информирования потребителя о спецификации альтернативной схемы на основе связанного с ней значения. 
  При использовании дискриминатора  встроенные схемы  не учитываются. 
  Фиксированные поля  
Карта     Имя поля 
 Тип 
 Описание 
 
    имя свойства 
  струна  
  ТРЕБУЕТСЯ  . Имя свойства в полезных данных, которое будет содержать значение дискриминатора. 
   отображение  [ строка ,  строка ] 
 Объект для хранения сопоставлений между значениями полезной нагрузки и именами схем или ссылками. 
 
 
  Объект дискриминатора допустим только при использовании одного из составных ключевых слов  oneOf  ,  anyOf  ,  allOf  . 
  В OAS 3.0 полезная нагрузка ответа МОЖЕТ быть описана как ровно один из любого количества типов: 
  MyResponseType:
  один из:
  - $ref: '#/components/schemas/Cat'
  - $ref: '#/компоненты/схемы/собака'
  - $ref: '#/components/schemas/Lizard'
 
 , что означает, что полезная нагрузка  ДОЛЖНА  при проверке соответствовать ровно одной из схем, описанных  Кошка  ,  Собака  или  Ящерица  . В этом случае дискриминатор МОЖЕТ действовать как «подсказка» для быстрой проверки и выбора соответствующей схемы, что может быть дорогостоящей операцией, в зависимости от сложности схемы. Затем мы можем точно описать, какое поле говорит нам, какую схему использовать: 
  MyResponseType:
  один из:
  - $ref: '#/components/schemas/Cat'
  - $ref: '#/компоненты/схемы/собака'
  - $ref: '#/components/schemas/Lizard'
  дискриминатор:
    имя_свойства: petType
 
  Теперь ожидается, что свойство с именем  petType   ДОЛЖНО  присутствовать в полезной нагрузке ответа, а значение будет соответствовать имени схемы, определенной в документе OAS. Таким образом, полезная нагрузка ответа: 
  {
  "идентификатор": 12345,
  "petType": "Кошка"
}
 
  Указывает, что схема  Cat  должна использоваться вместе с этой полезной нагрузкой. 
  В сценариях, где значение поля дискриминатора не соответствует имени схемы или неявное сопоставление невозможно, необязательный  сопоставление  определение МОЖЕТ использоваться: 
  MyResponseType:
  один из:
  - $ref: '#/components/schemas/Cat'
  - $ref: '#/компоненты/схемы/собака'
  - $ref: '#/components/schemas/Lizard'
  - $ref: 'https://gigantic-server. com/schemas/Monster/schema.json'
  дискриминатор:
    имя_свойства: petType
    сопоставление:
      собака: '#/компоненты/схемы/собака'
      монстр: 'https://gigantic-server.com/schemas/Monster/schema.json'
 
  Здесь значение дискриминатора   из  собака  будет отображаться на схему  #/components/schemas/Dog  , а не на значение по умолчанию (неявное)  Dog  . Если значение дискриминатора   не совпадает с неявным или явным сопоставлением, никакая схема не может быть определена, и проверка СЛЕДУЕТ завершиться ошибкой. Ключи сопоставления ДОЛЖНЫ быть строковыми значениями, но инструменты МОЖЕТ преобразовывать значения ответов в строки для сравнения. 
  При использовании в сочетании с конструкцией  anyOf  использование дискриминатора позволяет избежать неоднозначности, когда несколько схем могут удовлетворять одной полезной нагрузке. 
  В обоих вариантах использования  oneOf  и  anyOf  все возможные схемы ДОЛЖНЫ быть явно перечислены. Чтобы избежать избыточности, дискриминатор МОЖЕТ быть добавлен к определению родительской схемы, и все схемы, содержащие родительскую схему в конструкции  allOf , могут использоваться в качестве альтернативной схемы. 
  Например: 
  Компоненты:
  схемы:
    Домашний питомец:
      тип: объект
      требуется:
      - тип питомца
      характеристики:
        тип питомца:
          тип: строка
      дискриминатор:
        имя свойства: petType
        сопоставление:
          собака Собака
    Кошка:
      все:
      - $ref: '#/components/schemas/Pet'
      - тип: объект
        # все остальные свойства, специфичные для `Cat`
        характеристики:
          имя:
            тип: строка
    Собака:
      все:
      - $ref: '#/components/schemas/Pet'
      - тип: объект
        # все остальные свойства, характерные для `Dog`
        характеристики:
          лаять:
            тип: строка
    Ящерица:
      все:
      - $ref: '#/components/schemas/Pet'
      - тип: объект
        # все остальные свойства, специфичные для `Lizard`
        характеристики:
          любитRocks:
            тип: логический
 
  такая полезная нагрузка: 
  {
  "petType": "Кошка",
  "имя": "туманный"
}
 
  будет означать, что используется схема  Cat . Аналогично этой схеме: 
  {
  "petType": "собака",
  «кора»: «мягкая»
}
 
  будет отображаться в  Dog  из-за определения в элементе  mappings . 
  Объект XML 
  Объект метаданных, позволяющий более точно настроить определения модели XML. 
  При использовании массивов имена элементов XML равны , а не  (для форм единственного/множественного числа), и свойство имени   СЛЕДУЕТ использовать для добавления этой информации.
См. примеры ожидаемого поведения. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    имя 
  струна  
 Заменяет имя элемента/атрибута, используемого для описываемого свойства схемы. Когда он определен в  элементах  , он повлияет на имена отдельных элементов XML в списке. При определении рядом с  тип , являющийся массивом   (вне элементов   ), это повлияет на элемент упаковки, и только если  завернутый  равен  true  . Если  в оболочке  равно  false  , это будет проигнорировано. 
   пространство имен 
  струна  
 URI определения пространства имен. Значение ДОЛЖНО быть в форме абсолютного URI. 
   префикс 
  струна  
 Префикс для имени. 
   атрибут 
  логическое значение  
 Указывает, преобразуется ли определение свойства в атрибут, а не в элемент. Значение по умолчанию:  false  . 
   в упаковке 
  логическое значение  
 МОЖЕТ использоваться только для определения массива. Указывает, является ли массив упакованным (например,    ) или развернутым (   ). Значение по умолчанию:  false  . Определение вступает в силу только в том случае, если оно определено рядом с типом  , являющимся массивом   (вне элементов   ). 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Примеры объектов XML 
  Примеры определений объектов XML включены в определение свойства объекта схемы с образцом его XML-представления. 
  Нет XML-элемента 
  Свойство основной строки: 
  {
    "животные": {
        "тип": "строка"
    }
}
 
  животных:
  тип: строка
 
  <животные>...
 
  Свойство массива основных строк (  в оболочке  по умолчанию равно  false ): 
  {
    "животные": {
        "тип": "массив",
        "Предметы": {
            "тип": "строка"
        }
    }
}
 
  животных:
  тип: массив
  Предметы:
    тип: строка
 
  <животные>...
<животные>...
<животные>...
 
  Замена имени XML 
  {
  "животные": {
    "тип": "строка",
    "xml": {
      "имя": "животное"
    }
  }
}
 
  животных:
  тип: строка
  XML:
    имя: животное
 
  <животное>. ..
 
  XML-атрибут, префикс и пространство имен 
  В этом примере показано полное определение модели. 
  {
  "Человек": {
    "тип": "объект",
    "характеристики": {
      "я бы": {
        "тип": "целое",
        "формат": "int32",
        "xml": {
          "атрибут": правда
        }
      },
      "имя": {
        "тип": "строка",
        "xml": {
          "пространство имен": "http://example.com/schema/sample",
          "префикс": "образец"
        }
      }
    }
  }
}
 
  Лицо:
  тип: объект
  характеристики:
    я бы:
      тип: целое число
      формат: int32
      XML:
        атрибут: правда
    имя:
      тип: строка
      XML:
        пространство имен: http://example.com/schema/sample
        префикс: образец
 
  <Лицо>
    пример

 
  Массивы XML 
  Изменение имен элементов: 
  {
  "животные": {
    "тип": "массив",
    "Предметы": {
      "тип": "строка",
      "xml": {
        "имя": "животное"
      }
    }
  }
}
 
  животных:
  тип: массив
  Предметы:
    тип: строка
    XML:
      имя: животное
 
  <животное>значение
<животное>значение
 
  Внешнее свойство  name  не влияет на XML: 
  {
  "животные": {
    "тип": "массив",
    "Предметы": {
      "тип": "строка",
      "xml": {
        "имя": "животное"
      }
    },
    "xml": {
      "имя": "инопланетяне"
    }
  }
}
 
  животных:
  тип: массив
  Предметы:
    тип: строка
    XML:
      имя: животное
  XML:
    Название: пришельцы
 
  значение
<животное>значение
 
  Даже если массив упакован, если имя не определено явно, одно и то же имя будет использоваться как внутри, так и снаружи: 
  {
  "животные": {
    "тип": "массив",
    "Предметы": {
      "тип": "строка"
    },
    "xml": {
      "завернутый": правда
    }
  }
}
 
  животных:
  тип: массив
  Предметы:
    тип: строка
  XML:
    завернутый: правда
 
  <животные>
  <животные>значение
  <животные>значение

 
  Чтобы решить проблему именования в приведенном выше примере, можно использовать следующее определение: 
  {
  "животные": {
    "тип": "массив",
    "Предметы": {
      "тип": "строка",
      "xml": {
        "имя": "животное"
      }
    },
    "xml": {
      "завернутый": правда
    }
  }
}
 
  животных:
  тип: массив
  Предметы:
    тип: строка
    XML:
      имя: животное
  XML:
    завернутый: правда
 
  <животные>
  <животное>значение
  <животное>значение

 
  Влияет как на внутренние, так и на внешние имена: 
  {
  "животные": {
    "тип": "массив",
    "Предметы": {
      "тип": "строка",
      "xml": {
        "имя": "животное"
      }
    },
    "xml": {
      "имя": "инопланетяне",
      "завернутый": правда
    }
  }
}
 
  животных:
  тип: массив
  Предметы:
    тип: строка
    XML:
      имя: животное
  XML:
    Название: пришельцы
    завернутый: правда
 
  <инопланетяне>
  <животное>значение
  <животное>значение

 
  Если мы изменим внешний элемент, но не внутренние: 
  {
  "животные": {
    "тип": "массив",
    "Предметы": {
      "тип": "строка"
    },
    "xml": {
      "имя": "инопланетяне",
      "завернутый": правда
    }
  }
}
 
  животных:
  тип: массив
  Предметы:
    тип: строка
  XML:
    Название: пришельцы
    завернутый: правда
 
  <инопланетяне>
  <инопланетяне>значение
  <инопланетяне>значение

 
  Объект схемы безопасности 
  Определяет схему безопасности, которую могут использовать операции.
Поддерживаемые схемы: HTTP-аутентификация, ключ API (в виде заголовка, параметра cookie или параметра запроса), общие потоки OAuth3 (неявные, пароль, учетные данные клиента и код авторизации), как определено в RFC6749, и OpenID Connect Discovery. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Применяется к 
 Описание 
 
    тип 
  струна  
 Любой 
  ТРЕБУЕТСЯ  . Тип схемы безопасности. Допустимые значения:  "apiKey"  ,  "http"  ,  "oauth3"  ,  "openIdConnect"  . 
   описание 
  струна  
 Любой 
 Краткое описание схемы безопасности. Синтаксис CommonMark МОЖЕТ использоваться для форматированного текстового представления. 
   имя 
  струна  
  ключ API  
  ТРЕБУЕТСЯ  . Имя используемого заголовка, запроса или файла cookie. 
   в 
  струна  
  ключ API  
  ТРЕБУЕТСЯ  . Расположение ключа API. Допустимые значения:  "запрос"  ,  "заголовок"  или  "cookie"  . 
   схема 
  струна  
  http  
  ТРЕБУЕТСЯ  . Имя схемы авторизации HTTP, которая будет использоваться в заголовке авторизации, как определено в RFC7235. Используемые значения СЛЕДУЕТ зарегистрировать в реестре IANA Authentication Scheme. 
   форма носителя 
  струна  
  http  (  "носитель"  ) 
 Подсказка клиенту определить формат токена носителя. Токены-носители обычно генерируются сервером авторизации, поэтому эта информация предназначена в первую очередь для целей документации. 
   потоки 
 Объект потоков OAuth 
  оаут3  
  ТРЕБУЕТСЯ  . Объект, содержащий информацию о конфигурации для поддерживаемых типов потоков. 
   опенидконнектурл 
  струна  
  опенидконнект  
  ТРЕБУЕТСЯ  . URL-адрес OpenId Connect для обнаружения значений конфигурации OAuth3. Это ДОЛЖНО быть в форме URL. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Пример объекта схемы безопасности 
  Пример базовой аутентификации 
  {
  "тип": "http",
  "схема": "базовая"
}
 
  тип: http
схема: базовая
 
  Образец ключа API 
  {
  "тип": "апиКей",
  "имя": "api_key",
  "в": "заголовок"
}
 
  тип: APIKey
имя: API_key
в: заголовок
 
  Образец носителя JWT 
  {
  "тип": "http",
  "схема": "носитель",
  "bearerFormat": "JWT",
}
 
  тип: http
схема: носитель
носительФормат: JWT
 
  Неявный образец OAuth3 
  {
  "тип": "oauth3",
  "течет": {
    "скрытый": {
      "authorizationUrl": "https://example. com/api/oauth/dialog",
      "области": {
        "write:pets": "изменить питомцев в вашем аккаунте",
        "read:pets": "читать своих питомцев"
      }
    }
  }
}
 
  тип: oauth3
потоки:
  скрытый:
    URL-адрес авторизации: https://example.com/api/oauth/dialog
    области:
      write:pets: изменить питомцев в своей учетной записи
      read:pets: читай своих питомцев
 
  Объект потоков OAuth 
  Позволяет настраивать поддерживаемые потоки OAuth. 
  Фиксированные поля 
     Имя поля 
 Тип 
 Описание 
 
    неявный 
 Объект потока OAuth 
 Конфигурация для неявного потока OAuth 
   пароль 
 Объект потока OAuth 
 Конфигурация для потока пароля владельца ресурса OAuth 
  учетные данные клиента 
 Объект потока OAuth 
 Конфигурация потока учетных данных клиента OAuth. Ранее называвшееся приложением   в OpenAPI 2. 0. 
   Код авторизации 
 Объект потока OAuth 
 Конфигурация потока кода авторизации OAuth. Ранее назывался  accessCode  в OpenAPI 2.0. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Объект потока OAuth 
  Сведения о конфигурации для поддерживаемого потока OAuth 
  Фиксированные поля  
Карта     Имя поля 
 Тип 
 Применяется к 
 Описание 
 
    URL-адрес авторизации 
  струна  
  oauth3  ( "неявный" ,  "код авторизации" ) 
  ТРЕБУЕТСЯ  . URL-адрес авторизации, который будет использоваться для этого потока. Это ДОЛЖНО быть в форме URL. 
   URL-адрес токена 
  струна  
  oauth3  ( "пароль" ,  "учетные данные клиента" ,  "код авторизации" ) 
  ТРЕБУЕТСЯ  . URL-адрес токена, который будет использоваться для этого потока. Это ДОЛЖНО быть в форме URL. 
   URL-адрес обновления 
  струна  
  оаут3  
 URL-адрес, используемый для получения токенов обновления. Это ДОЛЖНО быть в форме URL. 
   прицелы  [ строка ,  строка ] 
  оаут3  
  ТРЕБУЕТСЯ  . Доступные области для схемы безопасности OAuth3. Сопоставление между именем области действия и ее кратким описанием. Карта МОЖЕТ быть пустой. 
 
 
  Этот объект МОЖЕТ быть расширен за счет расширений спецификации. 
  Примеры объектов потока OAuth 
  {
  "тип": "oauth3",
  "течет": {
    "скрытый": {
      "authorizationUrl": "https://example.com/api/oauth/dialog",
      "области": {
        "write:pets": "изменить питомцев в вашем аккаунте",
        "read:pets": "читать своих питомцев"
      }
    },
    "Код авторизации": {
      "authorizationUrl": "https://example. com/api/oauth/dialog",
      "tokenUrl": "https://example.com/api/oauth/токен",
      "области": {
        "write:pets": "изменить питомцев в вашем аккаунте",
        "read:pets": "читать своих питомцев"
      }
    }
  }
}
 
  тип: oauth3
потоки:
  скрытый:
    URL-адрес авторизации: https://example.com/api/oauth/dialog
    области:
      write:pets: изменить питомцев в своей учетной записи
      read:pets: читай своих питомцев
  Код авторизации:
    URL-адрес авторизации: https://example.com/api/oauth/dialog
    tokenUrl: https://example.com/api/oauth/token
    области:
      write:pets: изменить питомцев в своей учетной записи
      read:pets: читай своих питомцев
 
  Security Requirement Object 
  Список необходимых схем безопасности для выполнения этой операции.
Имя, используемое для каждого свойства, ДОЛЖНО соответствовать схеме безопасности, объявленной в схемах безопасности в объекте компонентов. 
  Security Requirement Объекты, которые содержат несколько схем, требуют, чтобы все схемы ДОЛЖНЫ быть удовлетворены для авторизации запроса.
Это обеспечивает поддержку сценариев, в которых для передачи информации о безопасности требуется несколько параметров запроса или заголовков HTTP. 
  Когда список объектов требований безопасности определен для объекта OpenAPI или объекта операции, только один из объектов требований безопасности в списке должен быть удовлетворен для авторизации запроса. 
  Узорчатые поля 
     Полевая модель 
 Тип 
 Описание 
 
    {имя} 
 [ строка ] 
 Каждое имя ДОЛЖНО соответствовать схеме безопасности, которая объявлена в схемах безопасности в объекте компонентов. Если схема безопасности имеет тип  "oauth3"  или  "openIdConnect"  , то значение представляет собой список имен областей, необходимых для выполнения, и этот список МОЖЕТ быть пустым, если для авторизации не требуется указанная область. Для других типов схем безопасности массив ДОЛЖЕН быть пустым. 
 
 
  Примеры объектов требования безопасности 
  Требование безопасности без OAuth3 
  {
  "апи_ключ": []
}
 
  API_key: []
 
  Требование безопасности OAuth3 
  {
  "зоомагазин_аутент": [
    "написать: домашние животные",
    "читать: домашние животные"
  ]
}
 
  petstore_auth:
- напиши: домашние животные
- читать: домашние животные
 
  Дополнительная безопасность OAuth3 
  Дополнительная безопасность OAuth3, определенная в объекте OpenAPI или объекте операции: 
  {
  "безопасность": [
    {},
    {
      "зоомагазин_аутент": [
        "написать: домашние животные",
        "читать: домашние животные"
      ]
    }
  ]
}
 
  безопасность:
  - {}
  - petstore_auth:
    - напиши: домашние животные
    - читать: домашние животные
 
  Расширения спецификации 
  Хотя спецификация OpenAPI старается учесть большинство вариантов использования, в определенные моменты могут быть добавлены дополнительные данные для расширения спецификации. 
  Свойства расширений реализованы в виде шаблонных полей, которые всегда имеют префикс  "x-"  .  
9х-     Полевой шаблон 
 Тип 
 Описание 
 Любой 
 Разрешает расширения схемы OpenAPI. Имя поля ДОЛЖНО начинаться с  x-, например,  x-internal-id . Значение может быть  null  , примитивом, массивом или объектом. Может иметь любое допустимое значение формата JSON. 
  
  Расширения могут поддерживаться или не поддерживаться доступными инструментами, но они также могут быть расширены для добавления запрошенной поддержки (если инструменты являются внутренними или открытыми). 
  Безопасность Фильтрация 
  Некоторые объекты в спецификации OpenAPI МОГУТ быть объявлены и оставаться пустыми или быть полностью удалены, даже если они по своей сути являются ядром документации API. 
  Причина в том, чтобы обеспечить дополнительный уровень контроля доступа к документации.
Хотя это и не является частью самой спецификации, некоторые библиотеки МОГУТ разрешать доступ к частям документации на основе той или иной формы аутентификации/авторизации. 
  Два примера: 
  : Объект Paths МОЖЕТ быть пустым. Это может показаться нелогичным, но это может сказать зрителю, что он попал в нужное место, но не может получить доступ к какой-либо документации. У них по-прежнему будет доступ к информационному объекту, который может содержать дополнительную информацию об аутентификации. 
 Объект элемента пути МОЖЕТ быть пустым. В этом случае зритель будет знать, что путь существует, но не сможет увидеть какие-либо его операции или параметры. Это отличается от сокрытия самого пути от объекта Paths, потому что пользователь будет знать о его существовании. Это позволяет поставщику документации точно контролировать то, что может видеть зритель. 
  Приложение A: История изменений 
     Версия 
 Дата 
 Примечания 
 
    3. 0.3 
 20.02.2020 
 Выпуск исправления спецификации OpenAPI 3.0.3 
   3.0.2 
 08.10.2018 
 Выпуск исправления спецификации OpenAPI 3.0.2 
   3.0.1 
 06.12.2017 
 Выпуск исправления спецификации OpenAPI 3.0.1 
   3.0.0 
 26.07.2017 
 Выпуск спецификации OpenAPI 3.0.0 
   3.0.0-rc2 
 16.06.2017 
 rc2 спецификации 3.0 
   3.0.0-rc1 
 27.04.2017 
 rc1 спецификации 3.0 
   3.0.0-rc0 
 28.02.2017 
 Проект реализации спецификации 3.0 
   2,0 
 31.12.2015 
 Пожертвование Swagger 2.0 инициативе OpenAPI 
   2,0 
 08.09.2014 
 Выпуск Swagger 2.0 
   1,2 
 14.03.2014 
 Первоначальный выпуск официального документа. 
   1,1 
 22 августа 2012 г. 


 


Навигация по записям
Принцип работы постоянного тока: Устройство и принцип работы двигателя постоянного тока | Полезные статьи
Чпу станок на ардуино: самодельный cnc фрезерный станок arduino пошаговая инструкция


Похожие записи







31.08.2023
0 

Микросхема 358: datasheet на русском, применение, аналоги, назначение выводов









30.08.2023
0 

Радиозвонок схема: ДВЕРНОЙ РАДИОЗВОНОК









29.08.2023
0 

Электросхема ваз 2105 инжектор: Схема ВАЗ-2105 | 2 Схемы







Добавить комментарий Отменить ответ
Ваш адрес email не будет опубликован. Обязательные поля помечены *
Комментарий * 
Имя * 
Email * 
Сайт 
 

 





Рубрики
Автолюбителям
Датчик
Лайфхаки
Преобразователь
Своими руками
Схемы
Усилитель
Разное
  






 





© 2018 M-Gen 

Карта сайта

`тип`	9формат 0574	Комментарии
`целое число`	`инт32`	32 бита со знаком
`целое число`	`int64`	подписанный 64-битный (длинный)
`номер`	`поплавок`
`номер`	`двойной`
`струна`
`строка`	`байт`	символов в кодировке base64
`строка`	`двоичный`	любая последовательность октетов
`логический`
`строка`	`Дата`	Как определено `полная дата` — RFC3339
`строка`	`дата-время`	Как определено `дата-время` — RFC3339
`строка`	`пароль`	Подсказка пользовательскому интерфейсу, чтобы скрыть ввод.

Описание схем

РАННИЕ ДЕЗАДАПТИВНЫЕ СХЕМЫ

1.Домен нарушения связи и отвержения

2.Домен нарушенной автономии

3.Домен нарушенных границ

4.Домен направленности на других

5.Домен сверхбдительности и подавления эмоций

ПОЗИТИВНЫЕ СХЕМЫ

5 «Пример и схема ответа (Описание API)»

Примеры и схемы ответов

Нужно ли определять ответ?

Использование реалистичных значений в примере ответа

Форматируем JSON и используем подсветку синтаксиса кода

Стратегии документирования вложенных объектов

Дизайн в три колонки

Встраивание динамических ответов

Что насчет кодов ошибок?

Пример и схема ответа конечной точки SurfReport

Пример ответа

Следующие шаги

Схема описания соединителя поиска — Win32 apps

Что такое соединители поиска?

Как работают файлы описания соединителя поиска?

Что такое схема описания соединителя поиска?

Каковы основные части схемы?

Примеры файлов описания соединителя поиска

Дополнительные ресурсы

Популярные шаблоны и схемы Visio

Список дезадаптивных схем в схема-терапии и краткое описание схем

Потеря связи и отвержение:

Ограниченная автономия:

Схемы из сферы нарушения границ:

Схемы направленные на других:

Чрезмерной бдительности и запрета:

Схема кинематики токарного станка

Кинематическая схема токарно-винторезного станка

Получить консультацию

Проработать технологию, подобрать станок и инструмент

Схема Определение и значение | Dictionary.

ДРУГИЕ СЛОВА ДЛЯ схемы

Происхождение схемы

синоним этюд схемы

ДРУГИЕ СЛОВА ИЗ схемы

Слова поблизости схема

Слова, связанные со схемой

Как использовать схему в предложении

British Dictionary definitions for scheme

Производные формы схемы

Слово Происхождение схемы

Другие идиомы и фразы со схемой

Определение схемы и значение | Английский словарь Коллинза

Видео: произношение

Цитаты

Тенденции

На других языках

Связанные условия

SKOS Simple Knowledge Organization System Namespace Document

Что такое пирамидальная схема? Как это работает?

Ключевые выводы

Как работают финансовые пирамиды

Примечание

Типы пирамидальных схем

Многоуровневая маркетинговая пирамидальная схема

Электронная почта цепочки

Схемы Понци

Пример схемы пирамиды

Как рушатся схемы пирамид

Является ли пирамидальная схема незаконной в Соединенных Штатах?

Как успешны схемы пирамид?

Схемы пирамид — это то же самое, что и программы многоуровневого маркетинга?

Итог

Abstract

Введение

Результаты

Качественно улучшенная выборка модельных белков с помощью REHT

Ансамбль выборки гибких IDP с высоким зарядом и низкой гидрофобностью

Расшифровка переходных промежуточных продуктов метаморфического белка (RFA-H)

Модулированное закаливание самовоздействия воды облегчает преодоление энтропийного барьера и способствует конформационному поиску

Обсуждение

Методы