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

Не всегда легко понять, что на самом деле представляет собой приложение RESTFull и / или API, потому что существует некоторое недопонимание значения и области применения архитектурного стиля REpresentational State Transfer.

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

Кроме того, я был впечатлен такжеСообщение блога автора этого архитектурного стиля, Роя Филдинга, где он очень разочарован частым неправильным пониманием того, что API, основанные на глаголах http, являются Restfull, в частности он жалуется на связь между клиентом и сервером этих API в отношении их имен и структур данных ,

ссылка на сообщение в блоге:http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Я хочу попытаться дать только теоретическое объяснение арки REST. стиль, и я хотел бы знать другие точки зрения.

Ответы на вопрос(2)

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

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

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

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

Сильный акцент на ресурсах и их презентации через медиа-типы.

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

Особенно последнее правило, данное Роем Филдингом, часто нарушается из-за того, что он не позволяет клиенту обнаруживать ресурсы, так как конечная точка явно кодируется в клиенте / приложении. Также возвращаемый тип часто предопределен. Это приводит к большому количеству вопросов, связанных с 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, как REST.

 Ciro Corvino04 сент. 2016 г., 17:01
Спасибо за ваш ответ @Roman .. на самом деле, когда я впервые опубликовал эту тему, я не очень хорошо знал StackOverflow и сеть StackExchange, и теперь я также думаю, что, возможно, эта тема была бы лучше для программистов (я буду просить stackoverlflow мета ..). Я нахожу ваш пост очень приятным и согласен с вашим общим взглядом на REST. Я продолжаю свой OP ...

Первая часть

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

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

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

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

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

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

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

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

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

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

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

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

Вторая часть

более подробная информация о медиатипе и создании приложения RESTful

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

Вот почему "представительский перевод"!

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

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

проектирование УРИ для собственных ресурсов;

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

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

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

 Ciro Corvino29 авг. 2016 г., 15:39
Большое спасибо за ваши предложения, я рассмотрю их для пересмотра моего поста .. но я настаиваю, если вы заявите, что я сказал, что репрезентативность относится к государству, вы ошибаетесь, и многое .. потому что основной мотив, который подтолкнул меня написать этот пост, именно это ошибочное предположение .. далее, второй раздел, выделенный жирным шрифтом, подробно описывает, что находится в первом жирном шрифте. Если вы прочитаете мой пост и прокомментируете реальный контент, я был бы очень признателен
 Ciro Corvino29 авг. 2016 г., 14:46
Может быть, вы не читали мое объяснение, поскольку заявляете, что я «продолжаю репрезентативную ссылку на состояние». Я говорю, что репрезентативная ссылка относится к передаче. Было бы лучше, если бы вы прочитали до «конструктивного» комментирования. Спасибо
 deceze29 авг. 2016 г., 14:24
Не понизили, но я нахожу это объяснение довольно рекурсивным и повторяющимся. Вы продолжаете о«представительский» относится к государству по-видимому, никогда не получая действительно хорошее объяснение того, что это на самом деле означает ... Только мои 2 €.
 deceze29 авг. 2016 г., 14:49
Я прочитал это, и это то, что я ушел. Ваш жирный раздел в первом абзаце и жирный в середине повторяют ту же информацию ... Ябыло пытаясь оставить конструктивную критику, оставьте ее, если она вам не нравится.
 Ciro Corvino29 авг. 2016 г., 14:19
Я думаю, что конструктивный комментарий более полезен немотивированного понижения.

Ваш ответ на вопрос