Комментарии 13
Representations переводится как «представление». У клиента есть своё представление о ресурсе. Оно может меняться. Как мы помним из нашего примера, мы могли несколько раз изменять свой заказ. Для этого мы озвучивали свое представление того, как должен выглядеть наш заказ официанту, а тот, в свою очередь, повару.
Насколько я понимаю пример и REST, "мы" озвучивали "состояние" (S из REST) нашего заказа. А представление (R из REST) это немного другое. Использую то же пример, офицант и повар может иметь разные представления одного и тоже ресурса "https://ресторан/повар/заказы/заказ_для_столика_№4", например application/vnd.best.restaurant+waiter и application/vnd.best.restaurant+cook
Запросы офицанта
PUT https://ресторан/повар/заказы/заказ_для_столика_№4
content-type: application/vnd.best.restaurant+waiter
accept: application/vnd.best.restaurant+waiter
{
"первое блюдо": "суп с говядиной",
"горячее": "индейка в сливочном соусе",
"напиток": "лимонный компот"
}
GET https://ресторан/повар/заказы/заказ_для_столика_№4
accept: application/vnd.best.restaurant+waiter
{
"первое блюдо": "суп с говядиной",
"горячее": "индейка в сливочном соусе",
"напиток": "лимонный компот",
"статус": "в прогрессе"
}
Запросы повара (тот же ресурс - УРЛ, но другое представление - более понятное для повара)
GET https://ресторан/повар/заказы/заказ_для_столика_№4
accept: application/vnd.best.restaurant+cook
{
"первое блюдо": {
"название": "суп с говядиной",
"ингридиенты": ["10 грамм говядины", "500 грамм лука"]
},
"горячее": {
"название": "индейка в сливочном соусе",
"ингридиенты": ["индеейка или индеец", "соус по вкусу"]
},
"напиток": {
"название": "лимонный компот",
"ингридиенты": ["растворитель сока, со вкусом лимона", "вода"]
},
"статус": "в прогрессе"
}
Получается, что и REST – это совокупность правил – правил организации взаимодействия тех самых компонентов распределённого приложения, о которых мы говорили выше. Что-то вроде кодекса, написанного разработчиками для разработчиков. [...] Осталось понять, что это за правила.
Не, сначала надо понять, откуда вы взяли те правила, которые вы озвучиваете. Вы упоминаете некий "кодекс REST", но откуда конкретно вы его взяли?
Всё ништяк. Вопрос - зачем?
Можно просто в json засунуть доп.поле method:"create","read","update","delete" и всё в post гонять, но это слишком просто.
Прошу прощения, возможно, я не совсем правильно понял Ваш вопрос. Вы спрашиваете зачем было писать эту статью? Когда я начал изучать понятие REST я столкнулся с множеством противоречивой информации на просторах интернета. Сложив воедино несколько точек зрения более похожих на правду и понятных мне, я решил воспроизвести свое понимание вопроса в этой статье. Так как тема REST, как мне показалось, до сих пор не закрыта.
Я не совсем понимаю, зачем такое писать
Ну смотрите, есть 6 принципов, вот что вы написали?
Клиент-серверная архитектура. Вы клиент, официант – сервер. Вы можете обмениваться друг с другом информацией или чем-то еще. Вы – клиентская часть. Официант, повар и холодильник – серверная часть.
Суть не в общении, как таковом. Суть в отделении фронта от бека, или клиента от сервера API. И дальше каждый как продукт/код/компонента живут своей жизнью. Более того, могут меняться независимо и без влияния один на другое
Слоистая архитектура. Клиентов и серверов может быть много. Промежуточные элементы являются как клиентом для своего сервера, так и сервером для своего клиента. Каждый клиент может общаться только со своим сервером, а сервер – только со своим клиентом. Клиент не может общаться с сервером своего сервера. Помните, повар не принесет Вам жаркое лично.
Ну тут ладно, пойдет
Единый интерфейс. Способ общения компонентов обозначен определенным стандартом, манерами поведения
Суть не только в стандарте. Суть в том, что вы ожидаете в рамках концепции единое представление объекта. Я отдал индейку, у получил индейку. Для обоих сторон индейка выглядит что в запросе, что в ответе одинаково (если это конечно та же индейка). А если это другая индейка, то это другая индейка. Потому что вы должны иметь возможность указать, что именно с этой индейкой вы что-то хотите делать
Никто не хранит состояние. Новый сеанс общения – чистый лист.
Да конечно, никто не хранит :) Как вы себе это представляете? Это требование только для сервера, и только в контексте того, что если есть несколько запросов, то сервер не совсем должен использовать данные одного запроса для обработки другого.
Клиент хранит свое состояние аж бегом, иначе это будет разговор двух рыбок из мульта Немо
Более того, принцип естественное касается контекста сервера. Ясно что есть вы создали объект, а потом его попросили - то вы его получите. Но это потому, что он есть в принципе к моменту выполнения второго запроса, а не потому что до того был первый запрос. Это тонки но важный момент, а вы вашим обобщением просто ... я даже не знаю, как это описать
Кэширование. Всё-таки какую-то часто используемую информацию хранить можно.
Да, на стороне клиента, если сервер сказал, что "да, можно". Кеширование на стороне сервера вообще относится к реализации и никак или почти никак не относится к принципам
Код по запросу. Если нужно выполнить сценарий на стороне клиента, можно предоставить ему для этого все необходимое, пускай выполняет…
Ну хоть тут все неплохо
В целом, так откровенно нельзя. Вы пишете информацию, которая неточна, либо неверна.
Плюс всегда стоит помнить об идемпотентности, об которую крайне легко споткнуться в реальной жизни
Здравствуйте, огромное спасибо Вам за то, что уделили мне время и оставили свой комментарий. Для меня как начинающего разработчика очень важна обратная связь. Я постараюсь как можно подробнее Вам ответить.
Зачем такое писать, я ответил в предыдущем комментарии.
Суть не в общении, как таковом. Суть в отделении фронта от бека, или клиента от сервера API. И дальше каждый как продукт/код/компонента живут своей жизнью. Более того, могут меняться независимо и без влияния один на другое
По части отделения фронта от бека, позвольте с Вами не согласиться. REST это правила, которые больше применимы к серверной части, и организации работы и разделении именно ее компонентов. Так чтобы их, как Вы точно выразились, можно было бы заменять без влияния на окружения, что становится возможным как раз, при соблюдении определенных правил. Более подробно я описал это в главе «Один как все и все как один».
Суть не только в стандарте. Суть в том, что вы ожидаете в рамках концепции единое представление объекта. Я отдал индейку, у получил индейку. Для обоих сторон индейка выглядит что в запросе, что в ответе одинаково (если это конечно та же индейка). А если это другая индейка, то это другая индейка. Потому что вы должны иметь возможность указать, что именно с этой индейкой вы что-то хотите делать
Тут, я тоже с Вами не соглашусь. Само понятие интерфейс - совокупность методов и правил взаимодействия элементами системы. Следовательно суть единого интерфейса в едином способе взаимодействия, а не в едином представлении объектов участвующих в этом процессе.
Да конечно, никто не хранит :) Как вы себе это представляете? Это требование только для сервера, и только в контексте того, что если есть несколько запросов, то сервер не совсем должен использовать данные одного запроса для обработки другого...
В своей статье я повествую о REST, как о неком каноне, а не о том, как выглядит ситуация в реальности. К сожалению, как мне кажется, REST стало этаким просторечием. Термином REST называют любой API который далек от соблюдения требований REST. Например, реализацию одного из ключевых условий HATEOAS на практике я встречал всего два раза.
В целом, так откровенно нельзя. Вы пишете информацию, которая неточна, либо неверна.
Я описал свое понимание понятия, и ни в коем случае не призываю кого-либо всецело придерживаться моей точки зрения. Как сказано в предисловии моей статьи, это всего лишь дополнение к другим точкам зрения. Тема REST очень иронична. А ирония в том, что REST это понятие о едином представлении. Вроде бы, понятие единое, а вот его представлений множество…
Плюс всегда стоит помнить об идемпотентности, об которую крайне легко споткнуться в реальной жизни
Про идемпотентность, Вы очень верно подметили. Но ведь и индейку в реальной жизни вряд ли кто-то станет передавать по HTTP. Эта статья этакое введение в понятие, описание в общих чертах, начало для уже более детального и практического изучения. Прибережем идемпотентность как раз для этого случая.
Еще раз спасибо Вам за столь подробный комментарий. Если у Вас остались какие-то вопросы, я буду рад ответить на них.
REST это правила, которые больше применимы к серверной части, и организации работы и разделении именно ее компонентов.
А фронт по вашему это не использует? Понятно никто не запрещает использовать REST API для взаимодействия сервисов. А если вы реализуете B2B сервис - тоже не про то?
Понятно, так как есть сервер, то вроде бы как это про него. Но сервер без клиента мало полезен, поэтому это про "обоих"
Следовательно суть единого интерфейса в едином способе взаимодействия, а не в едином представлении объектов участвующих в этом процессе
В чем для вас единость? Что именно едино? Единость не бывает в вакууме. Это нечто общее для множества объектов числом более одного. Попробуйте сами для себя понять, что имено "едино"
Даже для создания/изменения/получения данных об "индейке" я использую по сути разные запросы. Но для каждого запроса индейка должно (согласно принципов) выглядеть одинаково. Если по разному - то надо писать сериализатор под каждый вид представления, а зачем?
В своей статье я повествую о REST, как о неком каноне, а не о том, как выглядит ситуация в реальности
В реальности много программеров говнокодят, но это не так важно, почему они так делают и что они при этом чувствуют, кроме как для тех, на кого они работают.
Есть концепция. Одна из многих. Вам нравится, не нравится ... на концепцию это не влияет. Можете свою написать.
Но ведь и индейку в реальной жизни вряд ли кто-то станет передавать по HTTP
Но ее можно уровнить на пол :) И клиенту будет интересно, это та же, либо другая :) Это уже шутка
----------------------------
К примеру состояние и кеширование вы не поняли :( Но я надеюсь, комментарии вам могут понять лучше суть "состояния". Вы конечно можете и дальше говорить о своем мнении, но код от этого лучше не станет
REST под сливочным соусом