Комментарии 19
HTML-отклик полностью сам себя описывает
Здесь и далее какая-то игра в наперстки. Ничто не мешает включить элементы HATEOAS в JSON, ничто не мешает убрать их из HTML. Все зависит от задач данного апи. В большинстве случаев было бы странно заставлять клиента начинать с "елдиной точки входа" и пробегать через N промежуточных запросов ради получения результата. Поэтому и существуют сваггер и апи доки.
Практика разошлась с описанной 20 лет назад теорией - бывает. А перегрузка и неправильное использование терминов в IT вещь в принципе нередкая.
Что толку от того, что отклик описывает сам себя, если это описание не машиночитаемое?
С языка сняли. Я бы только уточнил, что недостает этому описанию скорее машинопонимаемости, а не машиночитаемости.
Ну действительно, что и когда клиенту делать с этими follow-up links? Тут человек требуется, чтобы понять.
Некоторое движение в сторону машинопонимаемости есть в HYDRA: https://www.hydra-cg.com/.
У человека какая-то травма из-за изменения значения термина. REST-HTML никто делать не будет, это непрактично. Для эффективной разработки необходимо отделение данных от предоставления.
Всё, чего можно добиться - назвать json-api каким-то другим словом, не rest. Автор может придумать такой термин и форсить его, если захочет.
А как в REST-HTML использовать POST DELETE etc
А вот концептуально, при использовании HATEOAS, как происходит идентификация ресурсов на уровне логики клиента? Все эти популярные примеры показывают, что надо с сервера прислать список связанных ендпоинтов. НО сами-то ендпоинты не машино-документируемы. Как абстрактный движок правильного REST клиента будет выбирать, какой следующий эндпоинт ему нужен? Или это сугубо вопрос в сфере RPC и настоящий REST он по определению заточен на кнопочки для робота из мяса и никакой программной логики на клиенте быть не может.
( id, href ). Клиент должен знать 1) как отрендерить состояние ресурса во вьюшку и 2) как превратить id действия/реляций в виджет (кнопку или ссылку, например). Т.е. совсем без какого-то стандарта, разумеется, не обойтись — как минимум для действий и связей нужно стандартизировать все хорошо известные идентификаторы («parent», «next», «details», «create», «update», «delete» и т.п.) и их семантику.Т.е. по сути, клиент должен имплементировать некий «браузер внутри браузера», только язык разметки — JSON, с кастомными «элементами». Если бы у нас изначально нативным языком разметки был JSON, то недоумения бы не было ни у кого — берёшь и отдаёшь JSON, непосредственно готовый к рендерингу стандартным браузером. А так, возможно, проще напрямую отдавать HTML отрендереный на сервере, технология проверенная :)
Лично для меня подобные статьи из серии "Раньше было лучше". Ну, если и не лучше, то "по-другому".
Да, по-другому. Да, раньше веб был вебом. А теперь покажите мне ресурс, который агрегирует лишь с браузером пользователя и только для рюшечек в браузере создается. Мир меняется, подходы меняются, пусть и за основу взяты парадигмы из прошлого. А это не прекрасно ли, когда ребёнок растет? Когда он не просто продолжает быть полезным, он захватывает умы и становится одним из самых ходовых!
Мы программируем не ради программирования. В конечном итоге всё есть продукт. А текущая реальность такова, что продуктом является множество клиентов-потребителей апи. Поэтому на мой взгляд это не "забывание истины REST'а", а его адаптация под стать времени.
"Раньше летательными аппаратами называли только самолеты с бумажными крыльями и дирижабли, неправильно сегодня называть гиперзвуковые спмолеты летательными средствами-у них крылья металлические и они не дирижабль". Занудство чистой воды.
я думаю, тут занудство (или не занудство) не в этом. А в том, что раньше летательными аппаратами называли, то что летает. А сейчас летательными аппаратами называют, то что плавает. Потому-что, то что плавает, более практично оказалось в настоящем.
А если серьезно, то, что тут автору удалось сделать, так это заставить меня глянуть, все же, на туже статью википедии. И этот HATEOAS - там лишь один из принципов. Но, не единственный, как это можно заключить из статьи.
И, кстати, в этой статье упоминаются стандарты, как в json указывать эти самые гирперлинки. Как было замечено в одном из комментариев, конечно, клиент должен понимать эти стандарты. Так же, как он должен понимать html стандарт для самого первого примера из статьи.
Так что, может и не "все так плохо", как рисует автор статьи? Молодежи (и не молодежи) надо только ознакомиться с этими links, embedded и тп. и за чем они нужны. А другие принципы (stateless, кеширование, ид в uri и т.п.), как мне кажется, более известны среднему разработчику, который пишет rest api, пусть и в стиле rcp.
Я тут, кстати, потихоньку делаю клиента для amocrm. В его api как раз и полно этих всяких embedded. Они меня через чур раздражают. Теперь то я уцепился за ниточку, которая поможет прийти к пониманию, зачем так усложняют те же разработчики api для amocrm (и иметь ввиду при написании своих api). Ну, или понять, что это все чушь и переусложнение и успокоится на этом.
Еще раз. Автор, может сам не подозревая, прям таки заставил краем глаза посмотреть, что же такое rest и почему споры вокруг его. А сама статья тему не раскрывает (кмк).
Интересно, как именно автор предлагает отказаться от документации? Ну будет API клиент знать, что есть POST /document/create, а откуда он возьмёт формат данных?
Или типа идея в том, что SPA это плохо, и браузер должен вызвать GET /document/create, и там вернётся форма? Это уже устарело давно.
Если я прально понял проблему - REST+JSON - много головняка, стандартов, писанины. Если закрыть более простым и менее гемморойным протоколом чем html/xml, то возможно, муры писать будем меньше. Такой протокол/решение есть - https://github.com/Claus1/unigui
Интересно! Спасибо за статью
Не согласен с переводом "An HTML Response" как "HTML-отклик". В индустрии сложившийся практика именования коммуникации между сервером и клиентом это: запрос <-> ответ. Но ни как не "отклик". Очень уже режет глаза.
Как REST выродился в собственную противоположность