Как быть в ресурсном состоянии: Ресурсное состояние: что это такое и как в него войти

Содержание

Ресурсное состояние: что это такое и как в него войти

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

Фото: Pexels.com

Что такое ресурсное состояние

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

Как войти в ресурсное состояние

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

Фото: Pexels.com

На физическом уровне

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

Научитесь контролировать так называемые гормоны счастья – дофамин, серотонин, окситоцин и эндорфины. О том, как это сделать, мы писали в отдельном материале. К слову, если вы постоянно испытываете чувство усталости и подавленности, можно сдать анализ крови на гормоны.

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

Фото: Pexels.com

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

Не забывайте заботиться о себе: вовремя посещать косметолога, проходить обследования у специалистов, следить за здоровьем.

На психологическом уровне

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

Приемы, которые помогут войти в ресурсное состояние

Моделирование

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

Медитации

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

Фото: Pexels.com

Ведение списков и чек-листов

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

Фото: Pexels.com

Хвалите себя

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

Найдите камень благодарности

Один из методов, которые описывает автор бестселлера «Секрет» Ронда Берн, – это эффективная техника благодарности, которая помогает накопить силы и энергию для вхождения в ресурсное состояние. Для этого нужно найти небольшой круглый камень и мысленно заряжать его своим теплом и произносить слова благодарности за все, что у вас есть.

Найдите хобби

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

Фото: Pexels.com

Следите за своей речью

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

Фокусируйте внимание

По словам американского бизнес-тренера Энтони Роббинса, «куда направлен фокус, туда направляется и энергия». Поэтому старайтесь фокусироваться на приятных вещах и позитивных моментах.

Фото: Pexels.com

Что мешает войти в ресурсное состояние

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

Ограничивающие убеждения

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

Фото: Pexels.com

Стремление к совершенству

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

Вам также могут понравиться эти материалы:

Медитация для начинающих: как правильно медитировать

Как сделать так, чтобы желание исполнилось

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

Быть в курсе!

Раз в неделю делимся статьями и новостями на темы моды, красоты, осознанности и жизни звезд

5 самых понятных секретов – Ирина Прачёва – Блог – Сноб

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

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

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

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

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

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

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

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

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

Чек-лист активации пикового состояния: 7 шагов, как быть в ресурсе каждый день

Если вы умеете вводить себя в пиковое состояние (the peak state), сможете достичь невозможного. Это не какая-то мотивационная волшебная фишка, которая дает временный эффект.

Это огненный инструмент! Самое мощное оружие в руках любого человека.

Мы все умеем вводить себя в ресурсное или безресурсное состояние. Но проблема в том, что делаем это неосознанно. Нас не учили управлять своим состоянием.

Поэтому мы часто вводим себя в безресурсное состояние: опускаем плечи, дышим неглубоко, крутим страшные мысли в голове.

В середине апреля я был на тренинге Тони Роббинса UPW 2019 в Лондоне. Мы 7 часов тренировались не просто вводить себя в ресурсное состояние, а поднимали его до пикового.

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

Вы знаете, куда идете, как доберетесь, и ничто не может вас остановить.

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

3 фактора, которыми нужно управлять для входа в ресурсное состояние

Физиология

Положение тела напрямую влияет на состояние. То, как вы стоите, сидите влияет на то, что вы думаете и чувствуете.

Попробуйте прямо сейчас: встаньте прямо, ноги на ширине плеч, голова немного вверх, плечи расправлены. Вы тут же почувствуете себя более сильным и сфокусированным.

Если ваше тело слабое, вы ходите или сидите сгорбившись, то автоматически чувствуете себя хуже.

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

Речь

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

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

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

Фокус

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

Фокусируйтесь на приятных вещах, и ваше психическое состояние резко улучшится.

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

Внутренние факторы, которые выводят вас из ресурсного состояния

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

ФАКТОР 1. Ограничивающие убеждения

Убеждения – это фильтр восприятия, через который вы смотрите на этот мир. Есть объективная реальность: деревья, машины, дома, другие люди возможности, опасности.

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

Если вы придерживаетесь таких убеждений, как «Я не достоин», «У меня недостаточно ресурсов, чтобы добиться успеха», «Я недостаточно умен», это ограничивает вашу эффективность.

Подробнее о токсических убеждениях и том, как их устранить, читайте в нашем посте.

ФАКТОР 2. Откладывание

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

Чтобы убрать откладывание и начать делать больше прибыльных действий в GoldCoach даже есть 3-недельный онлайн-челлендж «Действия 10Х», где вы уберете откладывание и сопротивление, чтобы стать решительным «мастером действий».

ФАКТОР 3. Перфекционизм

Марк Твен говорил: «Постоянное совершенствование лучше, чем отложенное совершенство».

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

Перфекционизм редко встречается без прокрастинации. Обычно они идут рядом. Чтобы справиться с перфекционизмом, рекомендую делать по принципу «быстро и на 80%». Осознайте, что вы не будете делать идеально и приступайте.

Чек-лист пикового состояния

Это алгоритм, как привести себя в пиковое состояние и остаться в нем максимально долго.

Привести тело в тонус

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

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

Читать вдохновляющие книги

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

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

Окружать себя вдохновляющими людьми

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

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

Танцевать

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

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

Думать о хорошем

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

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

Есть суперфуды

Добавьте в рацион суперфуды. Эти продукты наполняют энергией и помогают поддерживать её на пике.

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

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

Признавать победы

Тим Деннинг говорит: «Каждый раз, когда вы хотите улучшить свое состояние и достичь пика, вспомните, чего невероятного вы достигли. Или сосредоточьтесь на том, чего собираетесь достичь».

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

P. S. Ваше будущее больше, чем ваше прошлое!

И вы можете начать создавать его уже скоро в 3-недельном онлайн-челлендже «Действия 10Х», перейдя в ресурсное состояние и совершая много прибыльных действий на высокой энергии…

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

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

[Видео] КВАНТОВЫЙ ШИФТ: Как за 5 дней сформировать новую идентичность [Видео] Как обрести уверенность в себе и железное здоровье (лучшие идеи с UPW 2019 Тони Роббинса)

Как жить в ресурсном состоянии

Общие правила

Настоящий мастер не ищет ресурсное состояние, настоящий мастер живет в ресурсном состоянии.

Утром — зарядка. Зарядка начинает день, дает стартовый импульс и разгоняет. Дальше остается только удерживать темп. Еще лучше — иметь бодрое утро.

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

Так же важно иметь здоровый сон. Во время сна мы отдыхаем лучше всего. Здоровый сон — основа наличия жизненных сил. Организуете?

Есть еще один важный момент, о котором обычно забывают — не ленитесь. Не лениться означает продолжать воплощать намеченное, не смотря на чувства вроде “ой, что-то мне не хочется сейчас”. Дело в том, что усталось состоит из физической усталости и чувства усталости. А чувство усталости — инструмент воздействия лени. Не ленитесь, не будете уставшими!

Если ресурса не хватает

Настоящий мастер не тот, кто не выпадает из ресурсного состояния, а тот, кто его быстро создает.

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

Если днем силы уже не те, то может быть, вы забыли расслабиться? Помните, что после расслабления нужно взбодриться, иначе можно остаться сонным и вялым.

Если вечером вы замечаете, что ресурс кончился, то это может быть правдой. Но — только временной, потому что все поправимо. Что восполняет силы? В первую очередь прогулка по улице. Хорошо, если по парку или лесу. А еще лучше не прогулка, а пробежка. Вы потратите немного физических сил, а в обмен получите мешок ресурса! Впрочем, тут нужно знать меру — это не должен быть марафон на 30 километров.

Что стоит иметь в виду

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

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

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

Да пребудет с вами сила! Ой, ресурс то есть.

Как сохранить себя на работе и в жизни?

Время – это главный ресурс для человека. Еще Иоганн Вольфганг Гете писал, что каждое потерянное мгновение – потерянное дело, потерянная польза. Понимая как дорога и уникальна каждая минута нашей жизни, в ежедневной суете мы забываем об этом и не можем понять себя и свои желания, увидеть свои истинные цели. Дни складываются в месяцы, а месяцы в года и «день сурка» становится ежедневной явью.

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

Сегодня я расскажу вам, как оставаться в ресурсном состоянии в жизни и на работе и иметь так называемые ДОЗы (прим. #сленгПавловской): Деньги, Отношения, Здоровье.

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

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

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

Как занять свое место в жизни и быть в ресурсе
Жизнь состоит из систем и у каждого в этих системах есть свои роли. Например, в системе «Я и партнер» можно занять только одну роль – роль супруга или супруги. Однако около 99% людей в какой-то момент уходят со своего партнерского места и начинают воспитывать, учить, шантажировать или манипулировать партнером, делая все то, что не предназначено для этой роли.

В этот момент партнер начинает выполнять функцию «мамы» (так как воспитывает и ругает именно мама). Заняв роль «мамы», следует понимать, что вы получите все «прелести» данной роли – например, с родителями не спят (прим. #сленгПавловской). Таким образом, последствия критики и воспитания мужа обратятся в реалиях в отсутствии секса или потерей денег в данной супружеской паре. Вернувшись на свое место в системе, отношения сразу наладятся.

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

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

Мы можем ощущать состояние нересурсности в таких ролях как женщина, жена и мама, но в роли «сотрудник» такой опции нет и работник должен быть на 100% в ресурсе. Поэтому надо разделять роли и четко выполнять свой функционал в рабочее время. И, поверьте, что энергия и силы сразу появятся.

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

Автор: Евгения Павловская, основатель Академии Системных решений, автор технологии мгновенных изменений 22 века

Ресурсное состояние — что это такое?

Само по себе модное словосочетание ресурсное состояние вызывает массу вопросов:

что это такое?

чем характеризуется?

почему так звучит?

разное ли оно для каждого конкретного человека?

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

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

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

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

Почему так происходит?

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

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

как устроен мир,

что такое энергия,

бесконечность,

пространство,

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

Что необходимо удержать в фокусе рефлексии?

«Откуда брать энергию на ресурсное состояние?» – ключевой вопрос современного общества. Чем выше концентрация внимания на проблеме, тем больше она захватывает: время нахождения в проблеме увеличивается, а энергия уменьшается – ее не хватает для решения других задач. Таких задач в течение жизни человек решает тысячи. Причем подавляющее их число остается в подвешенном и не решенном состоянии, оставляя энергию человека в прошлом. Это касается в первую очередь отношений и эмоционального реагирования на разнообразные жизненные ситуации, когда мы разбрасываем свое внимание, теряя время и энергию жизни. Растрачивание жизненной энергии происходит по очень простому принципу: если человек что-то не завершил или его внимание осталось в каком-то событии, в этом месте появляется его собственный контролер этого факта, постоянно потребляющий определенный объем энергии. Если таких контролеров в течение жизни накопилось тысячи, то вся эта масса начинает вызывать состояние депрессии и недовольства жизнью, создавать проблемы со здоровьем. Показательной здесь является деятельность человека в системе многозадачности, когда возникает огромное число внутренних контролеров, а также присутствует фактор переключения и одновременного оставления части энергии внимания, что нередко приводит к полному физическому и морально-эмоциональному опустошению. Забирая же обратно «застрявшее» внимание, человек возвращает себе истраченную жизненную энергию к ресурсному состоянию. Можно говорить о собирании разбросанного внимания в течение жизни для увеличения энергетики, продления жизни и входа в то самое ресурсное состояние.

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

¹Имеется в виду рациональная его часть, умственные способности. – Прим. ред.

Как поддерживать свое ресурсное состояние?

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

Что такое ресурсное состояние и почему это важно?

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

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

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

Ресурсное состояние легче поддержать, чем восстановить.

Как следить за своим ресурсным состоянием?

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

rest — Как отличить состояние приложения от состояния ресурса

Позвольте мне процитировать один абзац из книги RESTful Web Services:

The Flickr веб-сервис позволяет загружать изображения в свою учетную запись, и эти изображения хранятся в сервер. Было бы безумием заставлять клиента отправлять все свои фотографии вместе с каждый запрос к flickr.com, чтобы сервер не сохранял какое-либо состояние

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

Еще одна цитата из той же книги, упомянутой ранее, прежде чем я вернусь к вам. Пример:

Состояние ресурса остается на сервере и отправляется только клиенту в виде представлений.Состояние приложения остается на client до тех пор, пока его нельзя будет использовать для создания, изменения или удаления ресурса. Затем он отправляется в сервер как часть запроса POST, PUT или DELETE и переходит в состояние ресурса.

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

Хорошее обсуждение SO о том, как этим управлять: действительно ли сеансы нарушают RESTfulness?

А что насчет того, что: просмотр корзины может привести вас к 2 различным действиям в зависимости от того, есть ли в ней товары или нет.
Довольно просто. То, что сервер обслуживает клиенту, зависит от состояния ресурса, поддерживаемого сервером.
Очень простой пример на этом хорошем сайте. Вы можете видеть, что в зависимости от суммы денег на счете, сервер предоставляет клиенту ссылку для вывода средств.
Клиент может свободно создавать собственное приложение (снова) и переходить по ссылке или нет.

Я рекомендую вам взглянуть на HATEOAS и модель зрелости Ричардсона, которая объясняет это. Кстати, цитаты из 2-х абзацев принадлежат тому же автору, что и эта модель.

REST — Без сохранения состояния

В соответствии с архитектурой REST (REpresentational «State» Transfer) сервер не хранит никакого состояния о клиентском сеансе на стороне сервера.Это ограничение называется Безгражданство . Каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания запроса, и не может использовать преимущества какого-либо хранимого контекста на сервере. Таким образом, состояние сеанса полностью зависит от клиента. Клиент отвечает за хранение и обработку всей информации, связанной с состоянием приложения, на стороне клиента .

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

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

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

Чтобы стать апатридом, не храните даже детали аутентификации / авторизации клиента. Укажите учетные данные с запросом. Каждый запрос ДОЛЖЕН быть автономным и не должен зависеть от предыдущего разговора с тем же клиентом в прошлом.

Состояние приложения и состояние ресурса

Не путайте состояние приложения и состояние ресурса. Оба совершенно разные вещи.

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

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

Отсутствие состояния в REST означает, что приложение находится в свободном состоянии.

Преимущества безгражданства

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

Без сохранения состояния помогает масштабировать API-интерфейсы для миллионов одновременных пользователей путем развертывания на нескольких серверах. Любой сервер может обработать любой запрос, потому что нет зависимости, связанной с сеансом.
Отсутствие состояния делает REST API менее сложными за счет удаления всей логики синхронизации состояния на стороне сервера.
API без сохранения состояния также легко кэшировать. Конкретное программное обеспечение может решить, следует ли кэшировать результат HTTP-запроса, просто просмотрев этот единственный запрос.Нет мучительной неуверенности в том, что состояние из предыдущего запроса может повлиять на кешируемость этого. Повышает производительность приложений.
Сервер никогда не теряет «где» каждый клиент находится в приложении, потому что клиент отправляет всю необходимую информацию с каждым запросом.

Ссылка: Рой Т. Филдинг о безгражданстве

Была ли эта статья полезной?

4. Ресурсно-ориентированная архитектура — веб-службы RESTful [Книга]

Глава 4.Архитектура, ориентированная на ресурсы

Я показал вам возможности REST, но не показал вам систематических как устроена эта власть или как ее раскрыть. В этой главе я очертить конкретную архитектуру RESTful: ориентированная на ресурсы Архитектура (РОА). ROA — это способ превратить проблему в RESTful веб-сервис: набор URI, HTTP и XML, который работает как остальная часть Интернета, и программисты будут пользоваться ею.

В главе 1 я классифицировал сеть RESTful services своими ответами на два вопроса.Эти ответы соответствуют две из четырех определяющих функций REST:

Информация об объеме («почему сервер должен отправлять эти данные вместо этих данных? ») хранится в URI. Это принцип адрес .
Информация о методе («почему сервер должен отправлять эти данные вместо его удаления? ») хранится в методе HTTP. Есть только несколько методов HTTP, и все заранее знают, что они делают.Этот является принципом единого интерфейса .

В этой главе я представляю движущиеся части Ресурсо-ориентированная архитектура: ресурсы (конечно), их названия, их представления и связи между ними. Я объясняю и продвигаю свойства ROA: адресуемость, отсутствие состояния, связность и единый интерфейс. Я показываю, как веб-технологии (HTTP, URI и XML) реализуют движущиеся части, чтобы сделать свойства возможными.

В предыдущих главах я проиллюстрировал концепции, указывая на существующие веб-сервисы, такие как S3. Я продолжаю эту традицию в этой главе, но я также проиллюстрирую концепции, указав на существующие веб-сайты. Надеюсь, я уже убедил вас, что веб-сайты — это веб-службы, и что многие веб-приложения (например, поисковые системы) являются веб- Сервисы. Когда я говорю об абстрактных понятиях, таких как адресуемость, полезно, чтобы показать вам реальные URI, которые вы можете ввести в свой веб-браузер, чтобы увидеть концепции в действии.

Что делать с ориентацией на ресурсы?

Почему появился новый термин — ресурсо-ориентированная архитектура? Почему не просто сказать ОТДЫХ? Ну, я говорю ОТДЫХ на обложке этой книги, и я считают, что все в ресурсо-ориентированной архитектуре также ОТДЫХ. Но REST — это не архитектура: это набор критериев проектирования. Можно сказать, что одна архитектура соответствует этим критериям лучше, чем другой, но не существует одной «архитектуры REST».

До сих пор люди имели тенденцию создавать одноразовые архитектуры как они разрабатывают свои услуги в соответствии со своим пониманием ОСТАЛЬНЫЕ.Наиболее очевидным результатом этого является широкое разнообразие REST-RPC. гибридные веб-сервисы, которые, по утверждению их создателей, являются RESTful. Я пытаюсь положить этому конец, представив набор конкретных правил построения веб-сервисы, которые действительно будут RESTful. В следующих двух главах я расскажу даже покажите простые процедуры, которым вы можете следовать, чтобы превратить требования в Ресурсы. Если вам не нравятся мои правила, вы хотя бы имеете представление о что вы можете изменить и оставаться в состоянии RESTful.

Как набор критериев проектирования, REST является очень общим.В частности, он не привязан к Интернету. В REST ничего не зависит от механики HTTP или структура URI. Но я говорю о web , поэтому я явно привязываю Ресурсно-ориентированная архитектура для веб-технологий. Я хочу поговорить о том, как выполнять REST с HTTP и URI, в конкретном программировании языков. Если в будущем появятся RESTful-архитектуры, которые не работают в Интернете их передовые методы, вероятно, будут похожи на ROA, но детали будут другими.Мы перейдем этот мост, когда мы подходим к этому.

Традиционное определение REST оставляет много открытого пространства, которые практикующие засеяли фольклором. Я намеренно иду дальше чем Рой Филдинг в его диссертации или W3C в их стандартах: I хотите расчистить часть этого открытого пространства, чтобы в фольклоре было место для превратиться в четко определенный набор передовых практик. Даже если бы REST был архитектура, было бы несправедливо называть мою архитектуру таким же название.Я бы связал свои эмпирические наблюдения и предложения с более общие мысли создателей Сети.

Моя последняя причина, по которой я придумал новый термин, заключается в том, что «ОТДЫХ» — это термин, используемый в религиозных войнах ботаников. Когда он используется, подразумевается обычно существует одна настоящая архитектура RESTful, и именно она спикер предпочитает. Люди, предпочитающие другую архитектуру RESTful не согласен. Фрагменты сообщества REST, несмотря на общее согласие по базовые вещи, такие как значение URI и HTTP.

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

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

Ресурс — это все, что достаточно важно, чтобы на него ссылались как на вещь в себе.Если ваши пользователи могут «захотеть создать гипертекстовую ссылку к нему, делать или опровергать утверждения о нем, извлекать или кэшировать представление его, включить его полностью или частично в виде ссылки в другое представление, аннотировать его или выполнять с ним другие операции », тогда вы должны сделать это ресурсом. ^[]

Обычно ресурс — это то, что может храниться на компьютере. и представлен в виде потока битов: документ, строка в базе данных или результат выполнения алгоритма.Ресурс может быть физическим объектом как яблоко, или абстрактное понятие, как храбрость, но (как мы увидим позже) представления о таких ресурсах обязательно разочаруют.

Вот некоторые возможные ресурсы:

Версия 1.0.3 программного обеспечения
Последняя версия выпуска программного обеспечения
Первая запись в блоге от 24 октября 2006 г.
Дорога карта Литл-Рока, Арканзас
Некоторая информация о медузах
Справочник ресурсов, относящихся к медузам
Следующее простое число после 1024
Следующие пять простых чисел после 1024
Номера продаж для Q42004
Отношения между двумя знакомыми, Алисой и Боб
Список открытых ошибок в базе данных ошибок

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

Помните пример сеанса в Предисловии, когда я высмеивал HTTP 0.9? Допустим, это запрос HTTP 0.9. для http://www.example.com/hello.txt :

Запрос клиента	Ответ сервера
GET / привет.txt	Привет, мир!

Клиент HTTP манипулирует ресурсом, подключаясь к серверу который размещает его (в данном случае www.example.com ), и отправляя серверу метод («GET») и путь к ресурсу («/hello.txt»). Сегодняшний HTTP 1.1 немного сложнее, чем 0.9, но работает так же. Оба сервер и путь берутся из URI ресурса.

Запрос клиента	Ответ сервера
GET / привет.txt HTTP / 1.1 Хост: www.example.com	200 ОК Тип содержимого: текст / простой Привет мир!

Принципы, лежащие в основе URI, хорошо описаны Тимом Бернерсом-Ли в Universal Resource Идентификаторы — аксиомы веб-архитектуры. В этом разделе я изложить принципы построения URI и присвоения их Ресурсы.

Совет

URI — это фундаментальная технология Интернета. Существовал гипертекстовые системы до HTML и Интернет-протоколы до HTTP, но они не разговаривали друг с другом.URI связывает все эти Интернет-протоколы в Интернете, способ, которым соединены сети TCP / IP как Usenet, Bitnet и CompuServe в едином Интернете. Тогда Интернет перехватил эти другие протоколы и убил их, как и Интернет сделал с частными сетями.

Сегодня мы смотрим в Интернет (не Gopher), скачиваем файлы из Интернета. (не FTP-сайты), поиск публикаций в Интернете (не WAIS) и наличие разговоры в сети (не группы новостей Usenet).Контроль версий такие системы, как Subversion и Arch, работают через Интернет, в отличие от собственный протокол CVS. Даже электронная почта медленно перемещается в Интернет.

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

URI должны быть описательными

Вот первый момент, когда ROA строится на разреженных рекомендации тезиса REST и рекомендации W3C. я предположить, что ресурс и его URI должны иметь интуитивно понятный переписка. Вот несколько хороших URI для ресурсов, которые я перечислил выше:

http: // www.example.com/software/releases/1.0.3.tar.gz
http://www.example.com/software/releases/latest.tar.gz
http: // www.example.com/weblog/2006/10/24/0
http://www.example.com/map/roads/USA/AR/Little_Rock
http: // www.example.com/wiki/Jellyfish
http://www.example.com/search/Jellyfish
http: // www.example.com/nextprime/1024
http://www.example.com/next-5-primes/1024
http://www.example.com/sales/2004/ 4 квартал
http://www.example.com/relationships/Alice;Bob
http://www.example.com/bugs/by-state/open

URI должны иметь структуру. Они должны варьироваться в предсказуемой способы: не следует заходить в / search / Jellyfish для медуз и / i-want-to-know-about / Mice для мышей.Если клиент знает структуру URI сервиса, он может создавать свои собственные точки входа в сервис. Это позволяет клиентам легко использовать свои услуги способами, о которых вы даже не думали.

Это не абсолютное правило REST, как мы увидим в разделе «Назовите ресурсы» главы 5. Технически URI не обязательно должны иметь какую-либо структуру или предсказуемость, но я думаю, что они должны. Это одно из правил хорошего веб-дизайна, и он одинаково проявляется в гибридных сервисах RESTful и REST-RPC.

Взаимосвязь между URI и ресурсами

Давайте рассмотрим некоторые крайние случаи. Могут ли два ресурса быть одинаковыми? Могут ли два URI обозначать один и тот же ресурс? Может ли один URI обозначать два ресурса?

По определению, два ресурса не могут быть одинаковыми. Если бы они были то же самое, у вас будет только один ресурс. Однако в какой-то момент в раз два разных ресурса могут указывать на одни и те же данные. Если Текущая версия программного обеспечения — 1.0,3, то http://www.example.com/software/releases/1.0.3.tar.gz и http://www.example.com/software/releases/latest.tar.gz некоторое время будет ссылаться на один и тот же файл. Но идеи позади этих двух URI различаются: один из них всегда указывает на конкретная версия, а другие указывают на самую новую версию в то время, когда клиент обращается к нему. Это две концепции и две Ресурсы. Вы не будете указывать ссылку на последний при сообщении об ошибке в версии 1.0,3.

Ресурс может иметь один или несколько URI. Доступные номера продаж на http://www.example.com/sales/2004/Q4 может также быть доступным на http://www.example.com/sales/Q42004 . Если ресурс имеет несколько URI, клиентам проще ссылаться на ресурс. Обратной стороной является то, что каждый дополнительный URI разбавляет значение всех остальных. Некоторые клиенты используют один URI, некоторые — другой, и нет автоматического способа проверить, что все URI относятся к одному и тому же ресурс.

Совет

Один из способов обойти это — предоставить несколько URI для тот же ресурс, но пусть один из них будет «каноническим» URI для этот ресурс. Когда клиент запрашивает канонический URI, сервер отправляет соответствующие данные вместе с кодом ответа 200 («ХОРОШО»). Когда клиент запрашивает один из других URI, сервер отправляет код ответа 303 («См. также») вместе с каноническим URI. Клиент не видит, указывают ли два URI на один и тот же ресурс, но он может сделать два запроса HEAD и посмотреть, есть ли один URI перенаправляет к другому, или если они оба перенаправляют к третьему URI.

Другой способ — обслуживать все URI, как если бы они были то же самое, но укажите «канонический» URI в заголовке ответа Content-Location всякий раз, когда кто-то запрашивает неканонический URI.

Получение продаж / 2004/4 квартал может получить тот же поток байтов, что и при получении продаж / Q42004 , потому что это разные URI для того же ресурса: «продажи за последний квартал 2004 года». Получение релизов / 1.0.3.tar.gz может дать вы используете тот же поток байтов, что и при загрузке релизов / latest.tar.gz , но они разные ресурсы, потому что они представляют разные вещи: «версия 1.0.3 »и« последняя версия ».

Каждый URI обозначает ровно один ресурс. Если он обозначил больше чем один, это не будет ресурс Universal Идентификатор. Однако, когда вы получаете URI, сервер может отправить вам информация о нескольких ресурсах: одном запрошенном и другом, связанные.Когда вы загружаете веб-страницу, она обычно передает некоторые информация сама по себе, но также есть ссылки на другие веб-страницы. Когда вы получаете корзину S3 с помощью клиента Amazon S3, вы получаете документ который содержит информацию о сегменте и информацию о связанные ресурсы: объекты в корзине.

Теперь, когда я представил ресурсы и их URI, можно перейти к углубиться в две особенности ROA: адресуемость и безгражданство.

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

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

Рассмотрим реальный URI, который называет ресурс в жанре «каталог». ресурсов о медузах »: http://www.google.com/search?q=jellyfish. Эта медуза поиск — это такой же реальный URI, как и http://www.google.com. Если HTTP не был адресуемым, или если поисковая система Google не была адресным веб-приложением, я не сможет опубликовать этот URI в книге. Я должен вам сказать: «Откройте веб-соединение с google.com , введите «медуза» в поле поиска и нажмите «Поиск в Google» кнопка.

Совет

Это не академическая проблема. До середины 1990-х годов, когда URI ftp: // стали популярными для описания файлы на FTP-сайтах, людям приходилось писать что-то вроде: «Запустить анонимный сеанс FTP на ftp.example.com . Затем перейдите в каталог pub / files / и скачать файл file.txt . ” URI сделал FTP как адресуемый как HTTP. Теперь люди просто пишут: «Скачать ftp://ftp.example.com/pub/files/file.txt ». В шаги такие же, но теперь их можно выполнять на машине.

Но HTTP и Google имеют адресацию, поэтому я могу распечатать этот URI в книге. Вы можете прочитать его и ввести. Когда вы это сделаете, вы окажетесь там, где Я был, когда просматривал веб-приложение Google.

Затем вы можете добавить эту страницу в закладки и вернуться к ней позже. Ты можешь ссылку на него на собственной веб-странице. Вы можете отправить URI по электронной почте кому-нибудь еще. Если HTTP нельзя было адресовать, вам пришлось бы загрузить всю страницу и отправьте файл HTML как вложение.

Для экономии полосы пропускания вы можете настроить кеш HTTP-прокси в своей локальной сети. В первый раз кто-то запросы http://www.google.com/search?q=jellyfish, кеш сохранит локальную копию документа. В следующий раз кто-нибудь попадает в этот URI, кеш может обслуживать сохраненную копию вместо скачивая снова. Это возможно только в том случае, если на каждой странице есть уникальная идентифицирующая строка: адрес.

Можно даже связать URI: использовать один URI в качестве входных данных для другой.Вы можете использовать внешнюю веб-службу для проверки страницы HTML или перевести его текст на другой язык. Эти веб-сервисы ожидайте URI в качестве входных данных. Если бы HTTP не был адресован, у вас не было бы возможности сообщая им, на каком ресурсе вы хотите, чтобы они работали.

Сервис Amazon S3 доступен, потому что каждый сегмент и каждый объект имеет свой собственный URI, как и список ведра. Ведра и предметы которые еще не существуют, еще не являются ресурсами, но у них тоже есть свои URI: вы можете создать ресурс, отправив ему запрос PUT. URI.

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

Адресация — одна из лучших особенностей веб-приложений. Это позволяет клиентам легко использовать веб-сайты так, как это было раньше. дизайнеры и представить не могли.Следование этому правилу дает вам и вашему пользователям многие преимущества REST. Вот почему службы REST-RPC так общие: они сочетают адресуемость с программированием вызова процедуры модель. Вот почему я выставил максимальную оплату ресурсов во имя Ресурсо-ориентированная архитектура: потому что ресурсы — это своего рода вещи это адресно.

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

Не надо придираться к маленьким ребятам; давайте продолжим наш тур по свойства Google, рассматривая онлайн-службу электронной почты Gmail. С точки зрения конечного пользователя, существует только один URI Gmail: https: // mail.google.com/. Что бы вы ни делали, что бы части информации, которую вы получаете или загружаете в Gmail, вы никогда не сможете увидеть другой URI. Ресурс «Электронные сообщения о медузах» не адресуемым, как и «веб-страницы о медузах» Google. ^[] Но за кулисами, как я показал в главе 11, находится веб-сайт, к которому можно обращаться. Список писем сообщения о медузе имеет ли URI: это https://mail.google.com/mail/?q=jellyfish&search=query&view=tl.Проблема в том, что вы не являетесь потребителем этого веб-сайта. Веб-сайт на самом деле веб-сервис, а реальный потребитель — это программа на JavaScript. работает в вашем веб-браузере. ^[] Веб-служба Gmail адресуется, но веб-служба Gmail приложение, которое его использует, нет.

Адресуемость — одна из четырех основных характеристик ROA. Второй безгражданство. Я дам вам два определения безгражданства: несколько общее определение и более практическое определение, ориентированное на в сторону РОА.

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

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

В человеческой сети вы часто сталкиваетесь с ситуациями, когда ваш кнопка «Назад» в браузере работает некорректно, и вы не можете вернуться и вперед в истории вашего браузера. Иногда это потому, что вы выполнили безвозвратное действие, такое как размещение записи в блоге или покупка книги, но часто это происходит потому, что вы находитесь на веб-сайте, нарушающем принцип безгражданство.Такой сайт ожидает, что вы будете делать запросы в определенном порядок: A, B, затем C. Он запутывается, когда вы делаете запрос B в секунду time вместо того, чтобы переходить к запросу C.

Давайте снова рассмотрим пример поиска. Поисковая система — это сеть сервис с бесконечным количеством возможных состояний: хотя бы одно для каждую строку, которую вы можете найти. У каждого штата есть свой URI. Ты можешь запросите у службы каталог ресурсов о мышах: http://www.google.com/search?q=mice.Вы можете попросить каталог ресурсов о медузах: http://www.google.com/search?q=jellyfish. Если ты не удобно создавать URI с нуля, вы можете запросить у службы форма для заполнения: http://www.google.com/.

Когда вы запрашиваете каталог ресурсов о мышах или медузах, вы не получите весь каталог. Вы получаете сингл страница каталога: список из 10 или около того элементов поисковая система считает лучшие совпадения по вашему запросу.Чтобы получить больше каталога вы должны сделать больше HTTP-запросов. Второй и последующие страницы являются отдельными состояниями приложения, и им необходимо иметь свои собственные URI: что-то вроде http://www.google.com/search?q=jellyfish&start=10. В виде с любым адресным ресурсом вы можете передать это состояние приложение к кому-то другому, кэшировать его или добавить в закладки и вернуться к это позже.

Рисунок 4-1 представляет собой простую диаграмму состояний. показывает, как HTTP-клиент может взаимодействовать с четырьмя состояниями поиска двигатель.

Рисунок 4-1. Поисковая система без отслеживания состояния

Это приложение без отслеживания состояния, потому что каждый раз, когда клиент делает запрос, он возвращается туда, где он был начат. Каждый запрос полностью отключен от других. Клиент может делать запросы на эти ресурсы любое количество раз в любом порядке. Он может запросить страницу 2 «мышей» перед запросом страницы 1 (или не запрашивать страницу 1 вообще), и серверу все равно.

В качестве контраста на рис. 4-2 показан одни и те же состояния организованы статно, причем состояния разумно ведут в каждое Другой.Так разработано большинство настольных приложений.

Рисунок 4-2. Поисковая система с отслеживанием состояния

Это намного лучше организовано, и если бы HTTP был разработан так, чтобы Взаимодействие с отслеживанием состояния, HTTP-запросы могут быть намного проще. Когда клиент начал сеанс с поисковой системой, это могло быть автоматически загружает форму поиска. Не нужно отправлять никаких запросов данные вообще, потому что первый ответ был бы предопределен. Если клиент просматривал первые 10 записей в каталоге мышей и хотел увидеть записи 11–20, он мог просто отправить запрос, в котором говорилось «Start = 10».Не нужно было бы отправлять / search? Q = mice & start = 10 , повторяя исходные утверждения: «Я ищу и ищу мышей в конкретный.»

FTP работает следующим образом: у него есть понятие «рабочий каталог», который остается неизменным в течение сеанса, если вы его не измените. Ты может войти на FTP-сервер, cd to определенный каталог, и получает файл из этого каталога. Можно получить другой файл из того же каталога, не создавая второй cd команда.Почему нет поддержки HTTP это?

Состояние упростит отдельные HTTP-запросы, но значительно усложнить протокол HTTP. FTP-клиент — это гораздо больше сложнее, чем HTTP-клиент, именно потому, что состояние сеанса должны быть синхронизированы между клиентом и сервером. Это сложная задача даже в надежной сети, которой нет в Интернете.

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

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

Клиент также получает выгоду от безгражданства. Клиент может обработать каталог «mice» до страницы 50, добавить в закладки / search? q = mice & start = 500 и вернуться неделю спустя, не перебирая десятки состояний-предшественников. URI, который работает, когда вы часами погрузились в сеанс HTTP, будет работать. так же, как первый URI, отправленный в новом сеансе.

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

Самый распространенный способ преодолеть безгражданство — использовать свой версия HTTP-сессий framework. Когда пользователь впервые заходит на ваш сайт, он получает уникальную строку, которая идентифицирует его сеанс с сайтом. Строка может храниться в файле cookie, или сайт может распространять уникальную строку через все URI, которые он обслуживает конкретный клиент.Вот файл cookie сеанса, устанавливаемый Rails приложение:

 Set-Cookie: _session_id = c1c934bbe6168dcb904d21a7f5644a2d; path = /

Этот URI передает идентификатор сеанса в приложении PHP: http://www.example.com/forums?PHPSESSID=27314962133 .

Важно то, что бессмысленное шестнадцатеричное или десятичное число не государство. Это ключ к структуре данных на сервере, и структура данных содержит состояние. Нет ничего беззаботного URI с отслеживанием состояния: именно так сервер сообщает о возможных следующих состояниях клиенту.(Однако там — это что-то Не беспокойтесь о файлах cookie, о чем я рассказываю в книге «Проблемы с файлами cookie». К используйте аналогию с веб-браузером, файлы cookie ломают спину клиента веб-службы кнопку)

Подумайте о переменной запроса start = 10 в URI, встроенном в страницу HTML. обслуживается поисковой системой Google. Это сервер, отправляющий возможное следующее состояние к клиенту.

Но эти URI должны содержать состояние, а не просто укажите ключ к состоянию, хранящемуся на сервере. start = 10 означает что-то само по себе, и PHPSESSID = 27314962133 — нет. RESTfulness требует, чтобы состояние оставалось на стороне клиента и было передается на сервер для каждого запроса, который в этом нуждается. Сервер может подтолкнуть клиента к новым состояниям, отправив ссылки с отслеживанием состояния для клиент, за которым следует следовать, но он не может сохранять собственное состояние.

Состояние приложения и состояние ресурса

Когда мы говорим о «безгражданстве», что считается «состоянием»? Что разница между постоянными данными, полезными данными на стороне сервера это заставляет нас в первую очередь хотеть использовать веб-сервисы, и это заявляют, что мы пытаемся держаться подальше от сервера? Веб-сервис Flickr позволяет вы загружаете изображения в свою учетную запись, и эти изображения хранятся в сервер.Было бы безумием заставлять клиента отправлять все свои фотографии вместе с каждым запросом на flickr.com , просто чтобы сервер не необходимость хранить любое состояние. Это разрушило бы весь смысл служба. Но в чем разница между этим сценарием и состоянием о сеансе клиента, который, как я утверждаю, не следует сервер?

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

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

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

Состояние ресурса одинаково для каждого клиента, и его собственное место находится на сервере. Когда вы загружаете изображение на Flickr, вы создаете новый ресурс: новое изображение имеет свой собственный URI и может быть целью будущих запросов.Вы можете получить, изменить и удалить ресурс «изображение» через HTTP. Это там для все: Я тоже могу его принести. Картинка немного о ресурсном состоянии, и остается на сервере, пока клиент не удалит его.

Состояние клиента может отображаться, когда вы этого не ожидаете. Много сети службы заставляют вас подписаться на уникальную строку, которую они называют ключом API или ключ приложения. Вы отправляете этот ключ с каждым запросом, а сервер использует его, чтобы ограничить вас определенным количеством запросов в день.Например, ключ API для устаревшего API поиска Google SOAP: подходит для 1000 запросов в день. Это состояние приложения: это у каждого клиента разные. Как только вы превысите лимит, поведение сервис кардинально меняется: по запросу 1000 вы получаете свои данные, а по запросу 1001 вы получите ошибку. А пока я работаю по запросу 402 и сервис по-прежнему у меня работает нормально.

Конечно, нельзя доверять клиентам самосообщение об этом состояние приложения: слишком велик соблазн схитрить.Итак, серверы поддерживать такое состояние приложения на сервере, нарушая безгражданство. Ключ API похож на файл cookie Rails _session_id , ключ на стороне сервера. клиентская сессия, которая длится один день. Это нормально, но приходится платить за масштабируемость. Если служба должна быть распределены по нескольким машинам, каждая машина в кластере нужно знать, что вы по запросу 1001, а я по запросу 402 (технический термин: репликация сеанса ), так что каждая машина знает, как отказать вам в доступе и пропустить меня.В качестве альтернативы, балансировщик нагрузки должен убедиться, что каждый из ваши запросы отправляются на тот же компьютер в кластере (технический термин: сродство сеанса ). Безгражданство снимает это требование. Как сервис-дизайнер, вы нужно думать о репликации данных только тогда, когда вы ресурс состояние необходимо разделить на несколько машины.

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

Ресурс — это источник представлений, а представление — это просто некоторые данные о текущем состоянии ресурса.Большинство ресурсов сами элементы данных (например, список ошибок), поэтому очевидный представление ресурса — это сами данные. Сервер может представить список открытых ошибок в виде XML-документа, веб-страницы или текст, разделенный запятыми. Показатели продаж за последний квартал 2004 г. может быть представлен в числовом виде или в виде графической диаграммы. Много новостей сайты делают свои статьи доступными в формате, загруженном рекламой, и в урезанный «удобный для печати» формат.Это все разные представления одних и тех же ресурсов.

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

Рассмотрим физический объект, автомат с газировкой, подключенный к сети. служба. ^[] Цель состоит в том, чтобы позволить клиентам машины избегать лишние поездки к машине.Благодаря услуге клиенты знают, когда газировка холодная, и когда их любимая марка распродана. Никто ожидает, что физические банки с газировкой будут доступны через Интернет сервис, потому что физические объекты не являются данными. Но у них есть данные около их: метаданные. Каждый слот в автомате с газировкой может быть оснащенный устройством, которое знает вкус, цену и температура ближайшей доступной банки соды. Каждый слот может быть выставлен в качестве ресурса, как и автомат по производству газированных напитков в целом.Метаданные из инструменты могут быть использованы для представления ресурсов.

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

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

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

Выбор между представлениями

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

Есть несколько способов выяснить это в ограничения REST. Самый простой и тот, который я рекомендую для Архитектура, ориентированная на ресурсы, заключается в предоставлении отдельного URI каждому представление ресурса. http://www.example.com/releases/104.en может обозначить английское представление пресс-релиза, и http://www.example.com/releases/104.es может обозначают испанское представительство.

Я рекомендую этот метод для приложений ROA, потому что он означает URI содержит всю информацию, необходимую серверу для выполнения запрос. Недостаток, так как всякий раз, когда вы открываете несколько URI для того же ресурса — разбавление: люди, которые говорят о прессе выпуск на разных языках, похоже, говорит о разных вещи. Вы можете несколько смягчить эту проблему, открыв URI http://www.example.com/releases/104 означает выпускать как платоническую форму, не зависящую от какого-либо языка.

Альтернативный способ называется согласованием содержимого . В этом сценарий единственный доступный URI — это URI платонической формы, http://www.example.com/releases/104 . Когда клиент делает запрос для этого URI, он предоставляет специальный HTTP-запрос заголовки, которые сигнализируют о том, какие представления клиент желает принять.

Ваш веб-браузер имеет настройку языковых предпочтений: языки, на которых вы предпочитаете размещать веб-страницы.Браузер отправляет это информация с каждым HTTP-запросом в Accept-Language заголовок. Сервер обычно игнорирует эту информацию, потому что большинство веб-сайтов страницы доступны только на одном языке. Но это соответствует тому, что мы есть пытаюсь сделать здесь: выставить разноязычные представления тот же ресурс. Когда клиент просит http://www.example.com/releases/104 , сервер может решить, обслуживать ли английское или испанское представительство на основе клиентского заголовка Accept-Language .

Совет

Поисковая система Google — хорошее место, чтобы попробовать это вне. Вы можете получить результаты поиска практически на любом языке, изменяя языковые настройки браузера или манипулируя hl переменная запроса в URI (например, hl = tr для турецкого). Поиск движок поддерживает согласование содержимого и различные URI для разные представления.

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

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

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

Вот простой пример этой дилеммы: валидатор HTML W3C, веб-сервис, доступный по адресу http: // validator.w3.org/. Вот URI ресурса на сайт W3C, отчет о проверке английской версии моего гипотетический пресс-релиз: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.example.com%2Freleases%2F104.en .

Вот еще один ресурс: отчет о проверке испанского версия пресс-релиза: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.example.com%2Freleases%2F104.es .

Каждый URI в вашем веб-пространстве становится ресурсом в сети W3C. приложение, независимо от того, обозначает ли оно отдельный ресурс в вашем сайт.Если в вашем пресс-релизе есть отдельный URI для каждого представление, вы можете получить два ресурса от W3C: проверка отчеты для английской и испанской версий прессы релиз.

Но если вы предоставляете URI только платонической формы и обслуживаете оба представления из этого URI, вы можете получить только один ресурс из W3C. Это будет отчет о валидации по умолчанию версия пресс-релиза (возможно английский).У вас нет возможности узнать, действительно ли Испанское представление содержит ошибки форматирования HTML. Если сервер не раскрывает испанский пресс-релиз как собственный URI, нет соответствующий ресурс доступен на сайте W3C. Это не значит вы не можете раскрыть этот URI платонической формы: просто он не должен быть только URI, который вы используете.

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

Иногда представления — это не что иное, как сериализованные данные конструкции. Они предназначены для того, чтобы их данные высосали и выбросили. Но в большинстве RESTful-сервисов представления — это гипермедиа: документы, содержащие не только данные, но и ссылки на другие Ресурсы.

Давайте снова рассмотрим пример поиска.Если вы перейдете в каталог Google документы о медузах, вы увидите результаты поиска и набор внутренних ссылок на другие страницы каталога. На рис. 4-3 показан репрезентативный образец страница.

Рисунок 4-3. Крупным планом на странице результатов поиска Google

Здесь данные и ссылки. Данные говорят, что где-то на В Интернете, кто-то сказал о медузе то-то и то-то, с акцентом на двух вид гавайских медуз. Ссылки дают вам доступ к другим ресурсы: некоторые в поисковой строке Google «веб-сервис», а некоторые в другом месте в Интернете:

Ранее в этой главе я показал, что могло бы произойти, если бы HTTP был протокол с отслеживанием состояния, такой как FTP.Рисунок 4-2 показывает пути, которые HTTP-клиент с отслеживанием состояния может пройти во время «сеанса» с www.google.com . HTTP на самом деле не работает способ, но этот рисунок хорошо показывает, как мы используем человеческий Интернет. Чтобы использовать поисковую систему, мы начинаем с домашней страницы, заполняем форму выполнить поиск, а затем щелкнуть ссылки, чтобы перейти на следующие страницы Результаты. Обычно мы не вводим один URI за другим: мы переходим по ссылкам и заполнять формы.

Если вы раньше читали о REST, вы могли столкнуться с аксиома из диссертации Филдинга: «Гипермедиа как двигатель состояние приложения.»Это то, что означает эта аксиома: текущее состояние HTTP-сеанс не сохраняется на сервере как состояние ресурса, но отслеживается клиентом как состояние приложения и создается путем клиент принимает через Интернет. Сервер указывает путь клиента, обслуживание «гипермедиа»: ссылки и формы внутри гипертекста представления.

Сервер отправляет клиенту инструкции о том, какие состояния близки текущий. Ссылка «следующая» на http: // www.google.com/search?q=jellyfish — это рычаг состояния : он показывает вам, как выйти из текущее состояние на родственное. Это очень мощно. Документ, который содержит URI, указывающий на другое возможное состояние приложения: «Страница вторая», или «относящаяся к этому URI», или «кешированная версия этого URI». Или это может указывать на возможное состояние совершенно другого применение.

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

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

Но большинство веб-сервисов не имеют внутренней связи, не говоря уже о том, чтобы связаны друг с другом. Amazon S3 — это веб-сервис RESTful, адресные и без гражданства, но не подключенные. Представления S3 никогда включать URI. Чтобы ПОЛУЧИТЬ ведро S3, вы должны знать правила для создание URI сегмента. Вы не можете просто ПОЛУЧИТЬ список желаний и перейдите по ссылке на нужное ведро.

Пример 4-1 показывает список ведра S3. что я изменил (я добавил тег URI ) так что это связано. Сравните с примером 3-5, в котором нет тега URI . Это всего лишь один из способов представить URI в XML-представление. По мере того, как ресурсы становятся более связанными, отношения между ними становятся более очевидными (см. рис. 4-4).

Пример 4-1. Связанный «список ваших сегментов»

 

 <Владелец>
   c0363f7260f2f5fcf38d48039f4fb5cab21b060577817310be5170e7774aad70 
   leonardr28 
 
 <Ведра>
  <Ведро>
    crummy.com 
    https://s3.amazonaws.com/crummy.com 
    2006-10-26T18: 46: 45.000Z

Рисунок 4-4.Одна услуга в трех направлениях

Во всем Интернете есть только несколько основных вещей, которые вы можете сделать к ресурсу. HTTP предоставляет четыре основных метода для четырех наиболее распространенных операции:

Получить представление ресурса: HTTP GET
Создайте новый ресурс: HTTP PUT в новый URI или HTTP POST на существующий URI (см. POST »ниже)
Изменить существующий ресурс: HTTP PUT to существующий URI
Удалить существующий ресурс: HTTP УДАЛИТЬ

Я объясню, как эти четыре используются для представления практически любых операция, о которой вы можете думать.Я также расскажу о двух методах HTTP для двоих менее распространенные операции: HEAD и OPTIONS.

Эти три должны быть вам знакомы из примера S3 в Глава 3. Чтобы получить или удалить ресурс, клиент просто отправляет запрос GET или DELETE на свой URI. В случае GET запрос, сервер отправляет обратно представление в ответе тело-сущность. Для запроса DELETE тело объекта ответа может содержат статусное сообщение или вообще ничего.

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

Опять же, подумайте о сервисе S3, где есть два типа ресурсы, которые вы можете создавать: корзины и объекты. Чтобы создать объект, вы отправляете запрос PUT на его URI и включаете содержимое объекта в тело объекта вашего запроса.Вы делаете то же самое, чтобы изменить объект: новый контент перезаписывает любой старый контент.

Создание корзины немного отличается, потому что у вас нет для указания тела объекта в запросе PUT. В ведре нет ресурса состояние за исключением его имени, и имя является частью URI. (Это не совсем так. Предметы в ведре также являются элементами этого состояние ресурса корзины: в конце концов, они перечислены, когда вы ПОЛУЧАЕТЕ представление ведра.Но каждый объект S3 — это собственный ресурс, поэтому не нужно манипулировать объектом через ведро. Каждый объект представляет собой единый интерфейс, и вы может управлять им отдельно.) Укажите URI сегмента, и вы уточнил свое представительство. Запросы PUT для большинства ресурсов выполняют включить тело объекта, содержащее представление, но, как вы можете видеть это не требование.

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

Вы видели метод HEAD, предоставленный ресурсами служб S3. в главе 3. Клиент S3 использует HEAD для выборки метаданные о ресурсе без загрузки, возможно, огромных тело-сущность. Вот для чего нужен HEAD. Клиент может использовать HEAD для проверки существует ли ресурс, или узнать другую информацию о ресурс без получения всего его представления. ГОЛОВА дает вам именно то, что даст вам запрос GET, но без тело-сущность.

Совет

Есть два стандартных метода HTTP, которые я не рассматриваю в этой статье. книга: TRACE and CONNECT. TRACE используется для отладки прокси, и CONNECT используется для пересылки некоторого другого протокола через HTTP. прокси.

Метод OPTIONS позволяет клиенту узнать, что ему разрешено делать с ресурсом. Ответ на запрос OPTIONS содержит HTTP Разрешить заголовок , в котором подмножество унифицированного интерфейса, поддерживаемого этим ресурсом.Вот образец Разрешить заголовок :

 Разрешить: GET, HEAD

Этот конкретный заголовок означает, что клиент может ожидать, что сервер действовать разумно по запросу GET или HEAD для этого ресурса, но это ресурс не поддерживает никаких других методов HTTP. Фактически, это ресурс доступен только для чтения.

Заголовки, которые клиент отправляет в запросе, могут влиять на Разрешить заголовок , который отправляет сервер отклик. Например, если вы отправляете правильный заголовок Authorization вместе с OPTIONS запроса, вы можете обнаружить, что вам разрешено использовать GET, HEAD, PUT и Запросы DELETE по определенному URI.Если вы отправите те же ОПЦИИ запрос, но опустить Авторизация заголовок, вы можете обнаружить, что вам разрешено использовать только GET и HEAD Запросы. Метод OPTIONS позволяет клиенту выполнять простой контроль доступа чеки.

Теоретически сервер может отправлять дополнительную информацию в ответ на запрос OPTIONS, и клиент может отправить OPTIONS запросы, которые задают очень конкретные вопросы о сервере возможности. Очень красиво, разве что нет общепринятых стандартов для что клиент может спросить в запросе OPTIONS.Помимо заголовка Allow нет принятых стандартов что сервер может отправить в ответ. Большинство веб-серверов и фреймворки очень плохо поддерживают ОПЦИИ. Пока что OPTIONS — это многообещающая идея, которой никто не пользуется.

Теперь мы подошли к самому непонятому из методов HTTP: POST. По сути, этот метод имеет два цели: тот, который соответствует ограничениям REST, и тот, который выходит за рамки REST и вводит элемент стиля RPC.В в подобных сложных случаях лучше вернуться к исходному тексту. Вот что RFC 2616, стандарт HTTP, говорит о POST (это из раздел 9.5):

POST разработан, чтобы обеспечить единообразный метод покрытия следующие функции:
Аннотация существующих ресурсов;
Размещение сообщения на доске объявлений, в группе новостей, в рассылке список или подобная группа статей;
Предоставление блока данных, например, результата отправка формы в процесс обработки данных;
Расширение базы данных с помощью операции добавления.
Определяется фактическая функция, выполняемая методом POST. сервером и обычно зависит от Request-URI. В отправленный объект подчиняется этому URI так же, как файл подчиняется содержащему его каталогу, новостная статья подчиняется группе новостей, в которой она размещена, или запись подчиняться базе данных.

Что это означает в контексте REST и ROA?

Создание подчиненных ресурсов

В дизайне RESTful POST обычно используется для создания подчиненных ресурсов: ресурсов, которые существуют в отношение к какому-либо другому «родительскому» ресурсу.Программа веб-журнала может представить каждый блог как ресурс ( / weblogs / myweblog ), а отдельные записи веб-журнала в качестве подчиненных ресурсов ( / weblogs / myweblog / entries / 1 ). А база данных с подключением к Интернету может предоставлять таблицу как ресурс, а отдельные строки базы данных в качестве подчиненных ресурсов. Чтобы создать запись в блоге или запись в базе данных, вы отправляете POST в родительский элемент: журнал или таблица базы данных. Какие данные вы публикуете и в каком формате это зависит от сервиса, но, как и в случае с PUT, в этом суть где состояние приложения становится состоянием ресурса.Вы можете увидеть это использование POST называется POST (a) , для «добавления». Когда я скажите «POST» в этой книге, я почти всегда имею в виду POST (a).

Почему нельзя просто использовать PUT для создания подчиненных ресурсов? Ну иногда ты можешь. Объект S3 является подчиненным ресурсом: каждый объект S3 является содержится в каком-то ведре S3. Но мы не создаем объект S3 отправка запроса POST в корзину. Мы отправляем запрос PUT напрямую в URI объекта.Разница между PUT и POST заключается в это: клиент использует PUT, когда он отвечает за решение, какой URI новый ресурс должен иметь. Клиент использует POST, когда Сервер отвечает за решение, какой URI новый ресурс должен иметь.

Служба S3 ожидает, что клиенты будут создавать объекты S3 с помощью PUT, потому что URI объекта S3 полностью определяется его именем и название ведра. Если клиент знает достаточно, чтобы создать объект, он знает, каким будет его URI.Очевидный URI для использования в качестве цель запроса PUT — это тот, который ведро будет жить сразу существует.

Но рассмотрим приложение, в котором на сервере больше контроль над URI: скажем, программа веб-журнала. Клиент может собрать вся информация, необходимая для создания записи в блоге, и все же не знаю, какой URI будет однажды создан в записи. Может сервер основывает URI на заказе или внутренний идентификатор базы данных: будет ли окончательный URI должен быть / weblogs / myweblog / entries / 1 или / weblogs / myweblog / entries / 1000 ? Может быть окончательный URI основан на времени публикации: во сколько сервер думаю, что это так? Клиенту необязательно знать эти вещи.

Метод POST — это способ создания нового ресурса без клиент должен знать свой точный URI. В большинстве случаев клиент необходимо знать только URI «родительского» или «фабричного» ресурса. В сервер берет представление из тела объекта и использует его для создать новый ресурс «под» «родительским» ресурсом ( значение «внизу» зависит от контекста).

Ответ на такой запрос POST обычно имеет HTTP код состояния 201 («Создано»).Его заголовок Location содержит URI вновь созданный подчиненный ресурс. Теперь, когда ресурс на самом деле существует, и клиент знает свой URI, будущие запросы могут использовать PUT метод для изменения этого ресурса, GET для получения его представления, и УДАЛИТЬ, чтобы удалить его.

Таблица 4-1 показывает, как запрос PUT к URI может создавать или изменять базовый ресурс; и как POST запрос к тому же URI может создать новый подчиненный ресурс.

Таблица 4-1. Действия PUT

NOST

	PUT на новый ресурс	PUT на существующий ресурс	POST
`/ weblogs` (ресурс уже существует)	Нет эффекта	Создать новый веб-журнал
`/ weblogs / myweblog`	Создать этот веб-журнал	Изменить настройки этого веб-журнала	Создать новую запись веб-журнала
/ myweblog / myweblog `1`	Н / Д (как бы вы получили этот URI?)	Отредактируйте эту запись веб-журнала	Добавьте комментарий к этой записи веб-журнала

Добавление к состоянию ресурса

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

Рассмотрим службу регистрации событий, которая предоставляет один ресурс: журнал. Скажем, его URI — / log . Чтобы получить журнал, отправьте GET запрос на / журнал .

Теперь, как клиент должен добавить в журнал? Клиент может отправить запрос PUT на номер / журнал , но метод PUT подразумевает создание нового ресурса или перезапись старых настроек с новые.Клиент тоже ничего не делает: он просто добавляет информация в конец журнала.

Метод POST работает здесь так же, как если бы каждая запись в журнале был выставлен как отдельный ресурс. Семантика POST — это то же самое в обоих случаях: клиент добавляет подчиненную информацию к существующий ресурс. Единственная разница в том, что в случае записи веб-журнала и веб-журнала, подчиненная информация отображалась как новый ресурс.Здесь подчиненная информация отображается как новая данные в родительском представлении.

Перегруженный POST: неоднородный интерфейс

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

Что такое «процесс обработки данных»? Звучит довольно расплывчато. И действительно, практически все может быть процессом обработки данных. Использование POST таким образом превращает ресурс в крошечный обработчик сообщений который действует как сервер XML-RPC. Ресурс принимает POST запрос, исследует запрос и решает сделать … что-то. Затем он решает предоставить клиенту … некоторые данные.

Я называю это использование POST перегруженным POST , по аналогии с перегрузкой оператора в программировании язык.Он перегружен, потому что используется единственный HTTP-метод. для обозначения любого количества методов, отличных от HTTP. Это сбивает с толку по той же причине перегрузка оператора может сбивать с толку: вы думали, что знал, что делает HTTP POST, но теперь он используется для достижения некоторых неизвестная цель. Вы можете увидеть перегруженный POST с именем POST (p) , для «процесса».

Когда ваша служба предоставляет перегруженный POST, вы повторно открываете вопрос: «почему сервер должен делать это вместо этого?» Каждый HTTP-запрос должен содержать информацию о методе, и когда вы используете перегруженный POST, он не может войти в метод HTTP.Метод POST просто указание серверу: «Загляните внутрь HTTP запросить информацию о реальном методе ». Реальная информация может быть в URI, заголовках HTTP или теле объекта. Однако это бывает, элемент стиля RPC закрался в служба.

Если информация о методе не найдена в методе HTTP, интерфейс перестает быть однородным. Информация о реальном методе может быть чем угодно.Мне как партизану REST это не очень нравится, но иногда это неизбежно. К главе 9 вы увидите, как любой сценарий, который вы только можете придумать, может быть предоставляется через унифицированный интерфейс HTTP, но иногда RPC style — это самый простой способ выразить сложные операции, охватывающие несколько ресурсов.

Вам может потребоваться открыть перегруженный POST, даже если вы только использование POST для создания подчиненных ресурсов или добавления в представление ресурса.Что, если один ресурс поддерживает оба виды ПОЧТЫ? Как сервер узнает, отправляет ли клиент POST для создания подчиненного ресурса или для добавления к существующему представительство ресурса? Возможно, вам потребуется добавить дополнительные информация о методе в другом месте HTTP-запроса.

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

Если вы раскрываете унифицированный интерфейс HTTP в том виде, в каком он был разработан, вы получите два полезных свойства бесплатно. При правильном использовании запросы GET и HEAD являются безопасными . Запросы GET, HEAD, PUT и DELETE идемпотент .

Запрос GET или HEAD — это запрос на чтение некоторых данных, а не запрос на изменение любого состояния сервера. Клиент может сделать GET или HEAD запрашивает 10 раз, и это то же самое, что делать это один раз или никогда делать это вообще.Когда вы ПОЛУЧАЕТЕ http://www.google.com/search?q=jellyfish, вы не изменить что-либо в каталоге ресурсов медуз. Вы просто получить его представление. Клиент должен уметь отправить запрос GET или HEAD на неизвестный URI и чувствовать себя в безопасности, ничего страшного не произойдет.

Это не означает, что запросы GET и HEAD не могут иметь сторонних последствия. Некоторые ресурсы являются счетчиками попаданий, которые увеличиваются каждый раз, когда клиент ПОЛУЧАЕТ их.Большинство веб-серверов регистрируют каждый входящий запрос в журнальный файл. Это побочные эффекты: состояние сервера и даже состояние ресурса меняется в ответ на запрос GET. Но клиент не спрашивал о побочных эффектах, и он не несет ответственности за их. Клиент никогда не должен делать запросы GET или HEAD только для побочные эффекты, и побочные эффекты никогда не должны быть настолько сильными, чтобы клиент может пожалеть, что не отправил запрос.

Идемпотентность — понятие немного хитрее.Идея исходит от математике, а если вы не знакомы с идемпотентностью, пример математики может помочь. Идемпотентная операция в математике — это такая же эффект независимо от того, применяете ли вы его один или несколько раз. Умножение число по нулю идемпотентно: 4 × 0 × 0 × 0 совпадает с 4 × 0. ^[] По аналогии, операция над ресурсом идемпотентна, если сделать один запрос — это то же самое, что сделать серию идентичных Запросы. Второй и последующие запросы покидают ресурс состояние точно такое же, как и в первом запросе.

Операции PUT и DELETE идемпотентны. Если вы УДАЛИТЕ ресурс, его больше нет. Если вы УДАЛИТЬ его снова, он все равно исчезнет. если ты создать новый ресурс с помощью PUT, а затем повторно отправить запрос PUT, ресурс все еще существует, и он имеет те же свойства, что и вы. когда вы его создали. Если вы используете PUT для изменения состояния ресурс, вы можете повторно отправить запрос PUT и состояние ресурса больше не изменится.

Практический результат состоит в том, что вы не должны позволять клиентов к представлениям PUT, которые изменяют состояние ресурса в относительные сроки.Если ресурс хранит числовое значение как часть своего состояние ресурса, клиент может использовать PUT, чтобы установить это значение на 4 или 0, или -50, но не для увеличения этого значения на 1. Если начальное значение равно 0, отправка двух запросов PUT, в которых говорится «установить значение 4», оставляет значение в 4. Если начальное значение равно 0, отправка двух запросов PUT которые говорят «увеличить значение на 1» оставляет значение не на 1, а на 2. Это не идемпотентный.

Почему важны безопасность и идемпотентность

Безопасность и идемпотентность позволяют клиенту создать надежный HTTP запросы по ненадежной сети.Если вы сделаете запрос GET и никогда не получите ответа, просто сделайте еще один. Это безопасно: даже если ваш предыдущий запрос был выполнен, он не оказал реального влияния на сервер. Если вы делаете запрос PUT и никогда не получаете ответа, просто сделай еще один. Если ваш предыдущий запрос получен, ваш второй запрос не будет иметь никакого дополнительного эффекта.

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

Наиболее частым неправильным использованием унифицированного интерфейса является раскрытие небезопасные операции через GET. API del.icio.us и Flickr сделай это. Когда вы ПОЛУЧАЕТЕ https://api.del.icio.us/posts/delete, вы не получение представления: вы изменяете данные del.icio.us задавать.

Почему это плохо? Ну вот и история. В 2005 Google выпустил клиентский инструмент кэширования под названием Web Accelerator.Он работает вместе с вашим Интернетом браузер и «предварительно выбирает» страницы, на которые есть ссылки с любой страницы вы смотрите. Если вы нажмете одну из этих ссылок, страница с другой стороны будет загружаться быстрее, потому что на вашем компьютере уже получил это.

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

Винить много: программисты не должны сообщать о небезопасных действиях с помощью GET, и Google не должен иметь выпустила реальный инструмент, который не работал с реальной сетью. Текущая версия Web Accelerator игнорирует все URI, содержащие переменные запроса. Это частично решает проблему, но также предотвращает использование многих ресурсов, которые можно безопасно использовать с помощью GET (например, Поисковые запросы Google) от предварительной выборки.

Умножьте примеры, если хотите. Многие веб-сервисы и сеть приложения используют URI в качестве входных данных, и первое, что они делают, — отправляют запрос GET для получения представления ресурса. Эти услуги не означают, что они вызывают катастрофические побочные эффекты, но это не до них. Служба должна обрабатывать запрос GET в способ, соответствующий стандарту HTTP.

Почему важен унифицированный интерфейс

Важность REST заключается не в том, что вы используете конкретный унифицированный интерфейс, который HTTP определяет.REST указывает единый интерфейс, но не говорит , который единый интерфейс. GET, PUT и все остальное не идеальный интерфейс на все времена. Что важно единообразие: все службы используют интерфейс HTTP одинаково способ.

Дело не в том, что GET — лучшее имя для операции чтения, но GET означает «читать» в Интернете, независимо от того, какой ресурс вы используете его. Учитывая URI ресурса, не может быть и речи о как вы получаете представление: вы отправляете HTTP-запрос GET на это URI.Единый интерфейс делает любые две службы такими же похожими, как и любые другие. два веб-сайта. Без единого интерфейса вам пришлось бы научиться каждая служба должна получать и отправлять информацию. Правила могут даже отличаться для разных ресурсов в пределах одного служба.

Вы можете запрограммировать компьютер, чтобы понять, что означает GET, и это понимание применимо к каждой веб-службе RESTful. Есть не так много нужно понимать. Код конкретной службы может находиться в обработка представительства.Без единого интерфейса вы получите Вместо GET используется множество методов: doSearch и getPage и nextPrime . Каждый сервис говорит по-своему язык. Это также причина того, что я не очень люблю перегружать POST много: он превращает простой эсперанто единого интерфейса в Вавилон одноразовых подъязыков.

Некоторые приложения расширяют унифицированный интерфейс HTTP. Большинство очевидным примером является WebDAV, который добавляет восемь новых методов HTTP, включая ПЕРЕМЕЩЕНИЕ, КОПИРОВАНИЕ и ПОИСК.Использование этих методов в веб-службе не приведет к нарушать любые предписания REST, потому что REST не говорит, что униформа интерфейс должен выглядеть так. Их использование нарушило бы мои Архитектура, ориентированная на ресурсы (я явно привязал ROA к стандартные методы HTTP), но ваш сервис все равно может быть ресурсоориентированный в общем смысле.

Настоящая причина не использовать методы WebDAV заключается в том, что они делает вашу службу несовместимой с другими службами RESTful.Ваш служба будет использовать единый интерфейс, отличный от большинства других Сервисы. Существуют веб-службы, такие как Subversion, которые используют WebDAV. методы, так что ваша служба не будет одинока. Но это было бы частью намного меньшей сети. Вот почему создание собственных методов HTTP очень, очень плохая идея: ваш собственный словарный запас помещает вас в сообщество одного. С таким же успехом вы можете использовать XML-RPC.

Другой унифицированный интерфейс состоит исключительно из HTTP GET и перегруженный POST.Чтобы получить представление ресурса, вы отправляете GET к его URI. Чтобы создать, изменить или удалить ресурс, вы отправляете POST. Этот интерфейс идеально подходит для RESTful, но, опять же, он не соответствует моя ресурсо-ориентированная архитектура. Этот интерфейс достаточно богатый чтобы различать безопасные и небезопасные операции. Ориентированный на ресурсы веб-приложение будет использовать этот интерфейс, потому что современные HTML-формы поддерживает только GET и POST.

Это ресурсо-ориентированная архитектура.Всего четыре концепции:

Ресурсы
Их имена (URI)
Их представления
Связи между ними

и четыре свойства:

Адресность
Связность
Единый интерфейс

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

ОТДЫХ, где мой штат? | Ruben Verborgh

HTTP , протокол передачи гипертекста, был разработан с учетом ограничений архитектурного стиля REST . Одним из хорошо известных ограничений этого стиля передачи состояния RE является то, что связь должна быть без сохранения состояния.Почему было введено именно это ограничение? И кто же тогда отвечает за поддержание состояния, поскольку это явно необходимо для многих веб-приложений? В этом посте объясняется, как безгражданство работает в современной сети, и объясняется разница между состоянием приложения и состоянием ресурса .

24 августа 2012 г.

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

Понимание двух разных типов состояний — ключ к пониманию безгражданства.
Безгражданство избавляет от необходимости помнить
Понятие безгражданства определяется с точки зрения сервера. Ограничение говорит, что сервер не должен запоминать состояние приложения. Как следствие, клиент должен отправлять всю информацию , необходимую для выполнения, вместе с каждым запросом, потому что сервер не может повторно использовать информацию из предыдущих запросов, поскольку он не запомнил их.
Конкретно это означает, что если вы просматриваете галерею изображений и сервер только что отправил вам изображение с номером 23, ваш клиент не может просто сказать серверу следующий .Вместо этого он запрашивает изображение 24 для продвижения в галерее. Действительно, ваш клиент должен предоставить всю информацию, необходимую для выполнения запроса, поскольку сервер не помнит, что вы просматривали изображение 23.
Хорошо, что вам, , также не нужно знать, что вы просматривали это изображение. конкретное изображение. Поскольку, наряду с представлением этого изображения, сервер может отправить вам ссылок , помеченных как «предыдущий» и «следующий» , ведущие к соответствующим изображениям.Разве это не противоречие? Нет, это не так: в то время, когда сервер генерировал представление изображения 23, сервер находился в середине обработки вашего запроса, поэтому знал , какое изображение вы запросили, и каковы были предыдущие и следующие изображения.
Концепция отправки представления ресурса вместе с элементами управления (например, ссылки) , которые ведут к следующим шагам, называется гипермедиа . Благодаря гипермедиа серверам не нужно запоминать состояние.Более того, клиентам не нужно заранее знать, какие шаги они могут предпринять, потому что вся эта информация содержится внутри гипермедийного представления.
Безгражданство делает веб-масштабирование
Филдинг приводит три важных свойства, которые вызваны безгражданством:
видимость
Каждый запрос содержит весь контекст, необходимый для его понимания. Следовательно, достаточно взглянуть на один запрос, чтобы визуализировать взаимодействие.
надежность
Поскольку запрос стоит сам по себе, отказ одного запроса не влияет на другие.
масштабируемость
Серверу не нужно запоминать состояние приложения, что позволяет ему обслуживать больше запросов за более короткий промежуток времени.
Масштабируемость оказалась особенно важной: человечество никогда не создавало взаимосвязанной сети, большей, чем Интернет.
Клиенты обрабатывают состояние приложения, состояние ресурсов сервера
Возможно, теперь вы задаетесь вопросом, почему у нас вообще есть возможность состояния в Интернете. Потому что, очевидно, если вы отправите твит, что-то изменится на сервере Twitter.Так что должна быть какая-то форма состояния сервера. Чтобы понять это в свете безгражданства, важно увидеть, что есть два типа государства. Существует состояние приложения , о котором мы говорили до сих пор, и состояние ресурса , с которым работают серверы состояний .
Состояние приложения — это информация о том, где вы находитесь во взаимодействии . Он используется во время сеанса работы с приложением. Например, тот факт, что вы просматриваете изображение 23, или тот факт, что вы вошли в систему в Twitter, являются состоянием приложения.Изменения этого состояния возможны с помощью элементов управления в представлениях гипермедиа. В случае с изображениями это ссылки, а в Twitter — поле и кнопка для твита.
Состояние ресурса — это вид (полу) постоянных данных , хранимых сервером, и длится дольше одного сеанса взаимодействия. Изображение, которое было загружено в галерею, и отправленный вами твит являются примерами состояния ресурса. Итак, как видите, хотя HTTP является протоколом без сохранения состояния, вы все равно можете иметь долгосрочное состояние на сервере.Тем не менее, краткосрочное состояние, которое используется во время вашего взаимодействия с сервером, является исключительной ответственностью вашего клиента, и он должен отправлять его в каждом запросе. Это делает web не имеющим состояния и, следовательно, масштабируемым .
D3D12_RESOURCE_STATES — Приложения Win32 | Документы Microsoft
05.12.2018
5 минут на чтение
В этой статье
Определяет константы, которые определяют состояние ресурса относительно того, как ресурс используется.
Синтаксис
typedef enum D3D12_RESOURCE_STATES { D3D12_RESOURCE_STATE_COMMON, D3D12_RESOURCE_STATE_VERTEX_AND_CONSTANT_BUFFER, D3D12_RESOURCE_STATE_INDEX_BUFFER, D3D12_RESOURCE_STATE_RENDER_TARGET, D3D12_RESOURCE_STATE_UNORDERED_ACCESS, D3D12_RESOURCE_STATE_DEPTH_WRITE, D3D12_RESOURCE_STATE_DEPTH_READ, D3D12_RESOURCE_STATE_NON_PIXEL_SHADER_RESOURCE, D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE, D3D12_RESOURCE_STATE_STREAM_OUT, D3D12_RESOURCE_STATE_INDIRECT_ARGUMENT, D3D12_RESOURCE_STATE_COPY_DEST, D3D12_RESOURCE_STATE_COPY_SOURCE, D3D12_RESOURCE_STATE_RESOLVE_DEST, D3D12_RESOURCE_STATE_RESOLVE_SOURCE, D3D12_RESOURCE_STATE_RAYTRACING_ACCELERATION_STRUCTURE, D3D12_RESOURCE_STATE_SHADING_RATE_SOURCE, D3D12_RESOURCE_STATE_GENERIC_READ, D3D12_RESOURCE_STATE_ALL_SHADER_RESOURCE, D3D12_RESOURCE_STATE_PRESENT, D3D12_RESOURCE_STATE_PREDICATION, D3D12_RESOURCE_STATE_VIDEO_DECODE_READ, D3D12_RESOURCE_STATE_VIDEO_DECODE_WRITE, D3D12_RESOURCE_STATE_VIDEO_PROCESS_READ, D3D12_RESOURCE_STATE_VIDEO_PROCESS_WRITE, D3D12_RESOURCE_STATE_VIDEO_ENCODE_READ, D3D12_RESOURCE_STATE_VIDEO_ENCODE_WRITE };
Константы
D3D12_RESOURCE_STATE_COMMON
Ваше приложение должно переходить в это состояние только для доступа к ресурсу через различные типы графических механизмов.
В частности, ресурс должен находиться в состоянии ОБЩИЙ перед использованием в очереди КОПИРОВАНИЯ (когда ранее использовался в ПРЯМОМ / ВЫЧИСЛЕННОМ) и перед использованием в ПРЯМОМ / ВЫЧИСЛЕННОМ состоянии (когда ранее использовался в КОПИРОВАНИИ). Это ограничение не существует при доступе к данным между очередями DIRECT и COMPUTE.
Состояние ОБЩЕЕ может использоваться для всех применений в очереди копирования с использованием неявных переходов между состояниями. Для получения дополнительной информации в разделе «Синхронизация нескольких двигателей» найдите «common».
Кроме того, текстуры должны находиться в ОБЩЕМ состоянии, чтобы доступ к ЦП был законным, при условии, что текстура изначально была создана в куче, видимой для ЦП.
D3D12_RESOURCE_STATE_VERTEX_AND_CONSTANT_BUFFER
Подресурс должен находиться в этом состоянии, когда к нему обращается графический процессор в качестве буфера вершин или буфера констант. Это состояние только для чтения.
D3D12_RESOURCE_STATE_INDEX_BUFFER
Подресурс должен находиться в этом состоянии, когда к нему обращается 3D-конвейер в качестве буфера индекса. Это состояние только для чтения.
D3D12_RESOURCE_STATE_RENDER_TARGET
Ресурс используется в качестве цели рендеринга.Подресурс должен находиться в этом состоянии, когда он отображается или очищается с помощью ID3D12GraphicsCommandList :: ClearRenderTargetView.
Это состояние только для записи. Для чтения из цели рендеринга в качестве ресурса шейдера ресурс должен находиться либо в D3D12_RESOURCE_STATE_NON_PIXEL_SHADER_RESOURCE, либо в D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE.
D3D12_RESOURCE_STATE_UNORDERED_ACCESS
Ресурс используется для неупорядоченного доступа. Подресурс должен находиться в этом состоянии, когда к нему обращается графический процессор через неупорядоченное представление доступа.Подресурс также должен находиться в этом состоянии, когда он очищается с помощью ID3D12GraphicsCommandList :: ClearUnorderedAccessViewInt или ID3D12GraphicsCommandList :: ClearUnorderedAccessViewFloat. Это состояние чтения / записи.
D3D12_RESOURCE_STATE_DEPTH_WRITE
D3D12_RESOURCE_STATE_DEPTH_WRITE — это состояние, которое является взаимоисключающим с другими состояниями. Вы должны использовать его для ID3D12GraphicsCommandList :: ClearDepthStencilView, когда флаги (см. D3D12_CLEAR_FLAGS) указывают, что данный подресурс должен быть очищен (в противном случае состояние подресурса не имеет значения), или при его использовании в представлении трафарета глубины с возможностью записи (см. D3D12_DSV_FLAGS), когда В PSO включена запись глубины (см. D3D12_DEPTH_STENCIL_DESC).
D3D12_RESOURCE_STATE_DEPTH_READ
DEPTH_READ — это состояние, которое можно комбинировать с другими состояниями. Его следует использовать, когда подресурс находится в представлении трафарета глубины только для чтения или когда параметр DepthEnable D3D12_DEPTH_STENCIL_DESC имеет значение false. Его можно комбинировать с другими состояниями чтения (например, D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE), чтобы ресурс можно было использовать для проверки глубины или трафарета и получить к нему доступ с помощью шейдера в том же вызове отрисовки.Использование его, когда глубина будет записана вызовом отрисовки или командой очистки, недопустимо.
D3D12_RESOURCE_STATE_NON_PIXEL_SHADER_RESOURCE
Ресурс используется с шейдером, отличным от пиксельного шейдера. Подресурс должен находиться в этом состоянии до того, как его прочитает любой этап (кроме этапа пиксельного шейдера) через представление ресурсов шейдера. Вы по-прежнему можете использовать ресурс в пиксельном шейдере с этим флагом, если у него также установлен флаг D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE.Это состояние только для чтения.
D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE
Ресурс используется с пиксельным шейдером. Подресурс должен находиться в этом состоянии, прежде чем он будет считан пиксельным шейдером через представление ресурсов шейдера. Это состояние только для чтения.
D3D12_RESOURCE_STATE_STREAM_OUT
Ресурс используется с потоковым выводом. Подресурс должен находиться в этом состоянии, когда к нему обращается 3D-конвейер как к целевому потоку.Это состояние только для записи.
D3D12_RESOURCE_STATE_INDIRECT_ARGUMENT
Ресурс используется как косвенный аргумент.
Подресурсы должны находиться в этом состоянии, когда они используются в качестве буфера аргументов, передаваемого косвенному методу рисования ID3D12GraphicsCommandList :: ExecuteIndirect.
Это состояние только для чтения.
D3D12_RESOURCE_STATE_COPY_DEST
Ресурс используется как место назначения в операции копирования.
Подресурсы должны находиться в этом состоянии, когда они используются в качестве места назначения операции копирования или операции blt.
Это состояние только для записи.
D3D12_RESOURCE_STATE_COPY_SOURCE
Ресурс используется в качестве источника в операции копирования.
Подресурсы должны находиться в этом состоянии, когда они используются в качестве источника операции копирования или операции blt.
Это состояние только для чтения.
D3D12_RESOURCE_STATE_RESOLVE_DEST
Ресурс используется как место назначения в операции разрешения.
D3D12_RESOURCE_STATE_RESOLVE_SOURCE
Ресурс используется в качестве источника в операции разрешения.

D3D12_RESOURCE_STATE_RAYTRACING_ACCELERATION_STRUCTURE Когда буфер создается с этим, как исходное состояние, это указывает на то, что ресурс представляет собой структуру трассировки лучей ускорение, для использования в ID3D12GraphicsCommandList4 :: BuildRaytracingAccelerationStructure, ID3D12GraphicsCommandList4 :: CopyRaytracingAccelerationStructure или ID3D12Device :: CreateShaderResourceView для D3D12_SRV_DIMENSION_RAYTRACING_ACCELERATION_STRUCTURE измерение.
D3D12_RESOURCE_STATE_SHADING_RATE_SOURCE
Начиная с Windows 10 версии 1903 (10.0; Сборка 18362) указывает, что ресурс представляет собой изображение с частотой затенения экранного пространства для затенения с переменной скоростью (VRS). Для получения дополнительной информации см. Затенение с переменной скоростью (VRS).
D3D12_RESOURCE_STATE_GENERIC_READ
D3D12_RESOURCE_STATE_GENERIC_READ — это логическая комбинация OR’d других битов состояния чтения. Это необходимое начальное состояние для кучи загрузки. Как правило, вашему приложению следует избегать перехода на D3D12_RESOURCE_STATE_GENERIC_READ, когда это возможно, поскольку это может привести к преждевременной очистке кеша или изменениям компоновки ресурсов (например, сжатию / распаковке), вызывая ненужные остановки конвейера.Вместо этого вы должны переводить ресурсы только в фактически используемые состояния.
D3D12_RESOURCE_STATE_PRESENT
Синоним D3D12_RESOURCE_STATE_COMMON.
D3D12_RESOURCE_STATE_PREDICATION
Ресурс используется для предикации.
D3D12_RESOURCE_STATE_VIDEO_DECODE_READ
Ресурс используется в качестве источника в операции декодирования. Примеры включают чтение сжатого битового потока и чтение из ссылок декодирования,
D3D12_RESOURCE_STATE_VIDEO_DECODE_WRITE
Ресурс используется как место назначения в операции декодирования.Это состояние используется для декодирования выходных данных и гистограмм.
D3D12_RESOURCE_STATE_VIDEO_PROCESS_READ
Ресурс используется для чтения видеоданных во время обработки видео; то есть ресурс используется в качестве источника в операции обработки, такой как кодирование (сжатие) видео.
D3D12_RESOURCE_STATE_VIDEO_PROCESS_WRITE
Ресурс используется для записи видеоданных во время обработки видео; то есть ресурс используется как место назначения в операции обработки, такой как кодирование (сжатие) видео.
D3D12_RESOURCE_STATE_VIDEO_ENCODE_READ
Ресурс используется в качестве источника в операции кодирования. Это состояние используется для ввода и ссылки оценки движения.
D3D12_RESOURCE_STATE_VIDEO_ENCODE_WRITE
Этот ресурс используется как место назначения в операции кодирования. Это состояние используется для целевой текстуры операции разрешения кучи вектора движения.
Примечания
Это перечисление используется следующими методами:
Требования
См. Также
Перечисления ядер
Использование ресурсных барьеров для синхронизации состояний ресурсов в Direct3D 12
состояний веб-приложения: что это такое и почему они важны?
Состояние: особое состояние, в котором что-то находится в определенное время.- Dictionary.com
Состояние может быть расплывчатым термином. В информатике мы говорим о множестве состояний: состояние приложения, состояние ресурса, состояние сеанса, состояние маршрутизатора, серверы без сохранения состояния… yadda, yadda, yadda. Какое тебе дело? Вам не все равно, потому что то, как мы, разработчики, думаем о состоянии и используем его при создании ваших веб-приложений, влияет на ваш пользовательский опыт . Решения о состоянии играют роль в скорости извлечения ресурсов, опыте пользователя при ошибках ввода недопустимой формы и актуальной информации о продуктах, и это лишь некоторые из них.В этом сообщении в блоге будет предпринята попытка пролить свет на понимание состояния применительно к созданию веб-приложений, чтобы вы и ваши разработчики могли лучше определить варианты разработки, необходимые для достижения пользовательского опыта, который вам нужен при создании следующей итерации вашего веб-присутствия. Мы рассмотрим Application State , Resource State и Session State , чтобы предоставить несколько примеров.
Состояние приложения
Состояние приложения (также известное как Состояние программы ) представляет собой совокупность всего необходимого для поддержания работы вашего приложения.Когда мы говорим о состоянии приложения, мы обычно имеем в виду состояние программы в том виде, в каком оно существует в содержимом ее памяти. Но что это означает практически? Как мне это понять? Это помогает мыслить крайностями. Что происходит с информацией и функциональностью вашего приложения, если сервер выйдет из строя и перезапустится? Вы теряете все, что было в памяти. Это одна из причин, по которой в веб-разработке мы часто используем контроллеры ресурсов без сохранения состояния, которые распространяют информацию, необходимую для работы вашего приложения, таким образом, который не зависит от хранения данных для извлечения в памяти сервера.
Состояние ресурса
Состояние ресурса относится к состоянию ресурсов, хранящихся на сервере. Это могут быть файлы, изображения, записи базы данных и т. Д. Состояние ресурса изменяется по мере добавления, изменения или удаления ресурсов. Одним из величайших достижений за последние двадцать лет в веб-разработке стало принятие архитектуры REST, которая представляет собой способ работы с веб-ресурсами без сохранения состояния. Каждый запрос в REST явно сообщает о своем предполагаемом действии на ресурсе и передает вместе с ним информацию, необходимую для выполнения этого действия.REST работает так. Допустим, вам нужны все истории в базе данных. Ваш запрос будет выглядеть как GET / stories. Допустим, вы хотите создать новую историю. Ваш запрос будет выглядеть так: POST / stories. Допустим, вы хотели найти эту историю. Ваш запрос становится GET / stories / 1. Вы уловили дрейф.
Но теперь мы находимся в мире, где даже REST растягивается. Приложения становятся настолько загруженными информацией, что выполнение нескольких HTTP-запросов для извлечения ресурсов с использованием традиционных конечных точек REST становится обременительным для производительности.
Введите GraphQL. GraphQL отходит от концептуальной модели «ресурсов», которая доминировала в последние десятилетия в веб-опыте людей, и вместо этого отдает предпочтение графу сущностей в качестве своей основной концепции. По мере того как мы работаем с данными все больше и больше в нынешней итерации веб-фильтрации, взаимосвязи все больше и больше значат для взаимодействия с пользователем. В GraphQL вы можете получить в одном GET-запросе очень конкретную информацию, используя аргументы вашей конечной точки GraphQL, для получения которых с использованием традиционного REST потребуется несколько циклов приема-передачи.
Состояние сеанса
Состояние сеанса отслеживает взаимодействие пользователя во время сеанса браузера. Он содержит статус связи между клиентом и сервером, и теперь мы широко используем его для описания того состояния, которое связано с идентификатором сеанса и http-файлами cookie. Это состояние сеанса, которое запоминает страницу, на которой вы были в последний раз, например, удерживает элементы вашей корзины, чтобы они все еще были там, если вы закроете браузер и вернетесь туда, где вы делали покупки раньше, и информирует веб-сайт о том, авторизованы ли вы. для просмотра определенной страницы.
Заключительные мысли
Понимание государственных дел. Знание того, где ваше приложение будет хранить информацию и что сделает работу пользователя максимально комфортной, зависит от решений, связанных с состоянием. Решения о состоянии могут создать более устойчивое веб-приложение, более быстрое извлечение ресурсов и должны быть учтены при рассмотрении вопросов безопасности. В следующий раз, когда вы создадите новую версию своего веб-сайта или запустите новое веб-приложение, поговорите со своими разработчиками о том, что вам следует учитывать при улучшении взаимодействия с пользователем при эффективном использовании состояния.
Команда: состояние mv — Terraform от HashiCorp
Основная функция состояния Terraform — для отслеживания привязок между адресами экземпляров ресурса в вашей конфигурации и удаленные объекты, которые они представляют. Обычно Terraform автоматически обновляет состояние в ответ на действия, предпринятые при применении плана, например удаление привязки для удаленного объекта, который теперь был удален.
Вы можете использовать terraform state mv в менее распространенной ситуации, когда вы хотите сохранить существующий удаленный объект, но отслеживать его как другой ресурс адрес экземпляра в Terraform, например, если вы переименовали блок ресурсов или вы переместили его в другой модуль в вашей конфигурации.
» использование
Использование: mv состояния терраформирования [параметры] НАЗНАЧЕНИЕ ИСТОЧНИКА
Terraform будет искать в текущем состоянии экземпляр ресурса, ресурс, или модуль, соответствующий заданному адресу, и в случае успеха он переместит удаленные объекты, в настоящее время связанные с источником, которые будут отслеживаться вместо этого по месту назначения.
И исходный, и целевой адреса должны использовать синтаксис адреса ресурса и они оба должны ссылаться на один и тот же тип объекта: вы можете перемещать только ресурс экземпляр в другой экземпляр ресурса, весь экземпляр модуля в другой весь экземпляр модуля и т. д.Кроме того, если вы перемещаете ресурс или экземпляр ресурса, то вы можете переместить его только на новый адрес с тот же тип ресурса.
Наиболее частое использование для terraform state mv — это когда вы переименовали ресурсный блок в вашей конфигурации или вы переместили ресурсный блок в дочерний модуль, в обоих случаях с намерением сохранить существующие объект, но отслеживая его под новым именем. По умолчанию Terraform поймет перемещение или переименование конфигурации ресурса в качестве запроса на удаление старой object и создайте новый объект по новому адресу, и поэтому terraform state mv позволяет отменить эту интерпретацию, предварительно прикрепив существующий объект на новый адрес в Terraform.
Предупреждение: Если вы используете Terraform в среде совместной работы, вы должен гарантировать, что когда вы используете terraform state mv для рефакторинга кода стремиться к тому, чтобы вы внимательно общались со своими коллегами, чтобы никто не вносит любые другие изменения между вашим изменением конфигурации и вашим terraform state mv , потому что в противном случае они могут случайно создать план, который уничтожит старый объект и создаст новый объект в новом адрес.
Эта команда также принимает следующие параметры:
-dry-run — Сообщает обо всех экземплярах ресурсов, которые соответствуют заданному обращайтесь, не «забывая» ни одного из них.
-lock = false — Не удерживать блокировку состояния во время операции. Это опасно, если другие могут одновременно запускать команды для одного и того же Рабочее пространство.
-lock-timeout = DURATION — Если блокировка не отключена с помощью -lock = false , поручает Terraform повторить попытку получения блокировки в течение определенного периода времени, прежде чем возвращает ошибку.Синтаксис продолжительности — это число, за которым следует время. буква единицы измерения, например «3 с» в течение трех секунд.
Для конфигураций с использованием удаленный бэкэнд только, terraform state mv также принимает вариант -игнорировать-удаленную-версию .
Для конфигураций с использованием местный только государственный МВ, terraform taint также принимает устаревшие варианты - состояние , - состояние и - резервное копирование .
» Пример: переименование ресурса
Переименование ресурса означает изменение конфигурации следующим образом:
-resource "packet_device" "worker" { + ресурс "packet_device" "helper" { #... }
Чтобы сообщить Terraform, что он должен рассматривать новый «вспомогательный» ресурс как переименование старого «рабочего» ресурса, вы можете связать указанное выше изменение конфигурации с помощью следующей команды:
состояние терраформирования mv packet_device.worker packet_device.helper
» Пример: переместить ресурс в модуль
Если вы изначально написали ресурс в корневом модуле, но теперь хотите провести рефакторинг его в дочерний модуль, вы можете переместить блок ресурсов в дочерний конфигурации модуля, удалив оригинал в корневом модуле, а затем выполните следующую команду, чтобы Terraform воспринимал это как ход:
состояние терраформирования mv packet_device.рабочий модуль.worker.packet_device.worker
В приведенном выше примере новый ресурс имеет то же имя, но другой модуль. адрес. Вы также можете одновременно изменить имя ресурса, если новый организация модуля предлагает другую схему именования:
состояние терраформирования mv packet_device.worker module.worker.packet_device.main
» Пример: переместить модуль в модуль
Вы также можете преобразовать весь модуль в дочерний модуль.в конфигурации, переместите блок модуля , представляющий модуль, в другой модуль, а затем объедините это изменение с помощью следующей команды:
mv-модуль состояния terraform.app module.parent.module.app
» Пример: переместить конкретный экземпляр ресурса, используя
count
Ресурс, определенный с помощью мета-аргумента count имеет несколько экземпляров, каждый из которых идентифицируется целым числом. Ты можешь выберите конкретный экземпляр, включив явный индекс в ваш заданный адрес:
$ terraform state mv 'packet_device.worker [0] '' packet_device.helper [0] '
Ресурс, который не использует count или for_each , имеет только один ресурс экземпляр, адрес которого совпадает с адресом самого ресурса, поэтому вы можете перейти с адреса, не содержащего индекса, на адрес, содержащий индекс, или наоборот, если тип адреса, который вы используете, соответствует тому, и как каждый ресурс настроен:
$ terraform state mv 'packet_device.main' 'packet_device.all [0]'
Скобки ( [, ] ) имеют особое значение в некоторых оболочках, поэтому вам может потребоваться цитировать или экранировать адрес, чтобы буквально передать его Terraform.Приведенные выше примеры показывают типичный синтаксис кавычек для оболочек в стиле Unix.
» Пример: перемещение ресурса, настроенного с помощью for_each
Ресурс, определенный с помощью мета-аргумента for_each имеет несколько экземпляров, каждый из которых идентифицируется строкой. Ты можешь выберите конкретный экземпляр, включив явный ключ в ваш заданный адрес.
Однако синтаксис для строк часто включает кавычки и символ кавычек. имеет особое значение в командных оболочках, поэтому вам нужно использовать соответствующие синтаксис кавычек и / или экранирования для используемой оболочки.Например:
Оболочки в стиле Unix, например, в Linux или macOS:
состояние терраформирования mv 'packet_device.worker ["example123"]' 'packet_device.helper ["example456"]'
Командная строка Windows ( cmd.exe ):
состояние терраформирования mv packet_device.worker [\ "example123 \"] packet_device.helper [\ "example456 \"]
PowerShell:
состояние терраформирования mv 'packet_device.worker [\ "example123 \"]' 'packet_device.helper [\ "example456 \"]'
Помимо использования строк вместо целых чисел, например, ключей, обработка for_each ресурсов аналогична count ресурсов и поэтому одинаковые комбинации адресов с индексными компонентами и без них действительно, как описано в предыдущем разделе.

Ресурсное состояние: что это такое и как в него войти

Что такое ресурсное состояние

Как войти в ресурсное состояние

На физическом уровне

На психологическом уровне

Приемы, которые помогут войти в ресурсное состояние

Моделирование

Медитации

Ведение списков и чек-листов

Хвалите себя

Найдите камень благодарности

Найдите хобби

Следите за своей речью

Фокусируйте внимание

Что мешает войти в ресурсное состояние

Ограничивающие убеждения

Стремление к совершенству

Быть в курсе!

5 самых понятных секретов – Ирина Прачёва – Блог – Сноб

Чек-лист активации пикового состояния: 7 шагов, как быть в ресурсе каждый день

3 фактора, которыми нужно управлять для входа в ресурсное состояние

Физиология

Речь

Фокус

Внутренние факторы, которые выводят вас из ресурсного состояния

ФАКТОР 1. Ограничивающие убеждения

ФАКТОР 2. Откладывание

ФАКТОР 3. Перфекционизм

Чек-лист пикового состояния

Привести тело в тонус

Читать вдохновляющие книги

Окружать себя вдохновляющими людьми

Танцевать

Думать о хорошем

Есть суперфуды

Признавать победы

Как жить в ресурсном состоянии

Общие правила

Если ресурса не хватает

Что стоит иметь в виду

Как сохранить себя на работе и в жизни?

Ресурсное состояние — что это такое?

Почему так происходит?

Что необходимо удержать в фокусе рефлексии?

Как поддерживать свое ресурсное состояние?

Читайте также

Не только work-life: 4 вида баланса, которых не менее важно придерживаться

Читайте также

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

Читайте также

Как найти личный work-life баланс? 9 советов Оксаны Стехиной

rest — Как отличить состояние приложения от состояния ресурса

REST — Без сохранения состояния

Состояние приложения и состояние ресурса

Преимущества безгражданства

Была ли эта статья полезной?

4. Ресурсно-ориентированная архитектура — веб-службы RESTful [Книга]

Глава 4.Архитектура, ориентированная на ресурсы

Что делать с ориентацией на ресурсы?

Совет

URI должны быть описательными

Взаимосвязь между URI и ресурсами

Совет

Совет

Состояние приложения и состояние ресурса

Выбор между представлениями

Совет

Совет

Создание подчиненных ресурсов

Добавление к состоянию ресурса

Перегруженный POST: неоднородный интерфейс

Почему важны безопасность и идемпотентность

Почему важен унифицированный интерфейс

ОТДЫХ, где мой штат? | Ruben Verborgh

Безгражданство избавляет от необходимости помнить

Безгражданство делает веб-масштабирование

Клиенты обрабатывают состояние приложения, состояние ресурсов сервера

D3D12_RESOURCE_STATES — Приложения Win32 | Документы Microsoft

В этой статье

Синтаксис