В чем состоят недоразумения в отношении слова "ОТДЫХ" и его значения

Ответ 1

Первая часть

Моя основная цель - сосредоточить внимание на причине имени "репрезентативная передача состояния".

Я думаю, что большинство недоразумений в REST подпадает под прилагательное "репрезентация". Большинство людей думают, что "репрезентативное" слово относится к состоянию ресурса и поэтому создает приложение, фокусирующееся на структурах объектов для передачи/передачи вызывающим клиентам. Но я думаю, что в центре внимания "передача", это передача быть "репрезентативным", и поэтому важными проектными приложениями (или api) являются использование "репрезентативной" способности сетевой системы REST, на которую они полагаются, для поддержки передачи между клиент-серверными компонентами.

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

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

В этом видении Ipertext\Ipermedia является центром всего архитектурного стиля, предложенного Филдингом, и ключевой концепцией, позволяющей этой парадигме работать, является "репрезентативная (государственная) передача".

Итак, мы можем понять, почему слово "репрезентация" относится к понятию "передача", а не к понятию "государство". Поскольку передача является репрезентативной (представительского типа), а это означает, что это система, которая управляет "передачами" и на которой опирается взаимодействие клиент-сервер, дать некоторые стандартные указания о представлении, то есть концепция медиа-типа (или MIME в веб-реализации REST), и это, на мой взгляд, главная причина имени "Передача государственного представительства".

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

Таким образом, front-end, первый клиент этой архитектуры, проходит через свои состояния, отображая представление состояний, сгенерированных компонентом или компонентами, которые он вызывает, поддерживая единый согласованный интерфейс, а не на "private" api.

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

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

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

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

Вторая часть

дополнительные сведения о медиатепе и создании приложений RESTful

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

Вот почему "репрезентативный перевод"!

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

Поэтому для создания приложений (или разъемов с точки зрения REST), придерживающихся стандартного REST и, следовательно, RESTful, означает:

• разработка uri для собственных ресурсов;

• делает эти uri всегда доступными для представлений, отправленных клиентам;

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

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

Ответ 2

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

Для меня REST - это передача состояния или данных, которые в настоящее время содержатся в определенном ресурсе от сервера к клиенту, или наоборот. Эта передача инициализируется клиентом посредством вызова определенных операций, которые предоставляет базовый протокол связи, на ресурсе. Аспект представления теперь является возвращенным стилем/вкусом/типом состояния/данных. Если клиент запрашивает что-то вроде Accept: "application/hal+json", "application/json", "text/html", он напрямую запрашивает у сервера представление состояния в любом из трех форматов (с предпочтением на ведущих), и сервер может решить, на основе его возможностей, какой из них будет возвращен. Определенные весовые предпочтения могут быть указаны также для повышения вероятности того, что сервер вернет этот медиа-тип, а не другой более общий.

REST по своей простоте на самом деле трудно реализовать в реальности, подробнее об этом позже. Помимо некоторых архитектурных ограничений Рой Филдинг внедряется, данная ссылка включает в себя еще один список вещей, которые необходимо соблюдать, чтобы вызвать услугу или API RESTful, которые были обобщены в следующем списке:

• API должен придерживаться и не нарушать базовый протокол. Altough REST используется по HTTP в большинстве случаев, он не ограничен этим протоколом.

• Сильная ориентация на ресурсы и их представление через медиа-типы.

• Клиенты не должны иметь начальных знаний или предположений о доступных ресурсах или их возвращенном состоянии ( "типизированный" ресурс) в API, но изучать их на лету через выданные запросы и анализировать ответы. Это дает серверу возможность легко перемещать arround или переименовывать ресурсы без нарушения реализации клиента.

Особенно последнее правило, данное Роем Филдингом, часто нарушается, не позволяя клиенту обнаруживать ресурсы, поскольку конечная точка явно кодируется в клиент/приложение. Также возвращаемый тип часто предварительно назначается. Это приводит к множеству вопросов, связанных с URI-дизайном, здесь, в StackOverflow, поскольку URI должен переносить семантику, чтобы разработчик мог поместить их в клиент.

Но также тип мультимедиа часто ограничивается только поддержкой application/json или application/xml, хотя они не имеют никакой семантики для фактического содержимого. XML специально был разработан, чтобы быть расширяемым, следовательно, X в его названии. Там уже много специальных типов на основе XML, жесткие рамки часто возвращают только application/xml, что накладывает нагрузку на клиента, зная, что ответ семантически означает.

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

Atom/RSS и Json-HAL часто рекомендуются, по крайней мере, для повышения требований HATEOAS, поскольку они предоставляют ссылки на другие ресурсы и, следовательно, помогают клиенту семантически понять, что определенная строка должна интерпретироваться как дополнительный ресурс, который он может действовать на. Тем не менее, клиенты по-прежнему не знают, какие данные он фактически обрабатывает. Поэтому следует разработать специальные типы носителей, которые поддерживают клиентов в понимании того, что все данные - и у них могут быть разные вкусы для одного и того же состояния ресурса, то есть один, который дает только обзорную презентацию в состоянии ресурса, в то время как другой тип носителя может содержать полный набор данных.

Это, на мой взгляд, привело Филдинг к следующему утверждению:

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

Вещь, которую REST пытается внедрить, - это четкое развязывание от клиентов к определенному набору API, например, веб-браузер не связан с определенным веб-сервером. Веб-браузер способен отображать большое количество HTML-страниц, заполненных изображениями или другими типами носителей, без нарушения. Развязка достигается за счет того, что клиент начинает с базового URL-адреса, а затем исследует новые возможности посредством интерпретации ответов. Таким образом, HATEOAS приводит к изменению состояния клиентов посредством следующих ссылок, заданных сервером по предыдущему запросу. Поэтому изменение на стороне сервера не тормозит никаких настоящих клиентов RESTful, поскольку они будут использовать только то, что они узнали из предыдущего ответа. Клиент, который ожидает, что ресурс X будет освобожден по пути Y и будет иметь состояние Z, с большой степенью вероятности нарушит смену сервера.

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

Реальная проблема заключается в следующем: как написать те медиа-типы, которые любой пользователь может понять. Произвольным я имею в виду нечто вроде автоматизированной системы, которая не имеет априорных знаний об API или услуге и, следовательно, должна изучать все через запрос/ответы. Поскольку государство и его представление могут прийти во множестве разных вкусов, обучение клиента тому, как данные должны интерпретироваться, является трудным делом. Семантическая обработка данных по-прежнему остается огромной областью исследований. Автоматизированная система должна знать, что определенные строки имеют определенную семантику и что что-то в URI шаблона, возвращаемом сервером, требует ввода, который выполняет эту семантику.

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

Как реакция на этот недостаток, многие разработчики пытаются проложить простой маршрут и поместить знания в клиент, который затем тесно связан с API и не будет легко реагировать на изменения самого API. Для нас, людей, довольно тривиально понять намерение URI, поэтому мы настаиваем на чистом URI-API. У пользователей есть предварительное предположение (основанное на наименовании или какой-либо документации), на что способен API, и, следовательно, сокращение REST до маркетингового термина.

Заблуждение, которое есть у многих людей, есть, как сказал Филдинг, что API, который работает на HTTP, считается RESTful. Также модель зрелости Ричардсона не так полезна в этой проблеме, а также что сообщество StackOverflow рассматривает все, что как-то связано с API через HTTP, как ОТДЫХ.