Аргументы против использования html в качестве носителя данных с HATEOAS? - PullRequest
Новая
       8

Аргументы против использования html в качестве носителя данных с HATEOAS?

0 голосов
/ 27 августа 2018

Я начал читать об использовании HATEOAS для приложения и подумал, что было бы неплохо использовать структурированный HTML для данных, а не использовать, например, json.

Пример ниже: 

{
    "name": "Alice",
    "avatar": "data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOyDZu6QdvCchPGolfO0o/XBs/fNwfjZ0frl3/zy7////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAABAALAAAAAAQABAAAAVVICSOZGlCQAosJ6mu7fiyZeKqNKToQGDsM8hBADgUXoGAiqhSvp5QAnQKGIgUhwFUYLCVDFCrKUE1lBavAViFIDlTImbKC5Gm2hB0SlBCBMQiB0UjIQA7"
    "links": [ {
        "rel": "self",
        "href": "http://localhost:8080/customer/1"
    },
    {
        "rel": "up",
        "href": "http://localhost:8080/customer"
    }, 
    {
        "rel": "orders",
        "href": "http://localhost:8080/customer/1/order"
    }
    ]
}

может быть переписано в HTML как: 

<html><head>
        <script type="text/javascript" src="/site-wide-script.js"></script>
        <script type="text/javascript" src="script.js"></script>
        <link rel="stylesheet" href="/site-wide-styles.css">
        <link rel="stylesheet" href="styles.css">
    </head>
    <body data-type="customer">
        <div data-attribute="name">Alice</div>
        <div data-attribute="avatar"><img src="data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOyDZu6QdvCchPGolfO0o/XBs/fNwfjZ0frl3/zy7////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAABAALAAAAAAQABAAAAVVICSOZGlCQAosJ6mu7fiyZeKqNKToQGDsM8hBADgUXoGAiqhSvp5QAnQKGIgUhwFUYLCVDFCrKUE1lBavAViFIDlTImbKC5Gm2hB0SlBCBMQiB0UjIQA7" alt="avatar"></div>

        <nav>
            <ul>
                <a href="http://localhost:8080/customer/1" rel="self">Info</a>
                <a href="http://localhost:8080/customer" rel="up">Customers</a>
                <a href="http://localhost:8080/customer/1/order" rel="customers">Orders</a>
            </ul>
            <ul>
                <form method="put">
                    <label>Name<input type="text" name="name"></label>
                    <label>Avatar<input type="file" name="avatar" accept="image/gif, image/jpeg"></label>
                    <input type="submit" value="Edit">
                </form>
            </ul>
            <ul>
                <form method="delete">
                    <input type="submit" value="Delete">
                </form>
            </ul>
        </nav>
    </body></html>

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

Моя идея состоит в том, чтобы создать очень прогрессивное веб-приложение, которое всегда предоставляет пользователю его возможности и которое в основном использует одни и те же site-wide-script.js и site-wide-stylesheet.css, чтобы изменять согласованное отображение вещей во всех представлениях пользовательского интерфейса. , Другой сценарий и таблица стилей могут потенциально использоваться для выполнения чего-то очень специфичного для сущности (например, более продвинутая проверка в некоторых случаях или динамическое добавление дочерних сущностей в тот же пользовательский интерфейс).

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

Существуют ли какие-либо аргументы против представления данных таким образом при выполнении HATEOAS, кроме очевидной разницы в размерах ответов?

  • Является ли оно недействительным согласно некоторым RFC?
  • Испытывался ли это где-то еще и не получилось (кажется, что большинство ресурсов HATEOAS используют примеры с json или xml)?
  • Есть ли данные, которые не могут быть представлены таким образом в хорошем смысле?

Ответы [ 2 ]

0 голосов
/ 19 декабря 2018

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

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

Судя по вашему примеру, вы уже определили тип документа, по крайней мере, неявно. Следовательно, кажется, что это просто вопрос предоставления спецификации и подачи документов под выделенный тип носителя (например, в строке text/emil+html)

Рекомендуемое чтение: API-интерфейсы REST должны работать с гипертекстом - блог Роя Филдинга, 2008-10-20

0 голосов
/ 31 августа 2018

Самая популярная реализация HATEOAS часто упоминается как сама сеть. HTML является реализацией HATEOAS.

Так что да. Если вы создаете наилучшее веб-приложение на основе HTML, вы делаете HATEOAS.

...