REST - GET возвращает результат, отличный от POST / PUT

Question

В нашем проекте книгу можно добавить, отправив структуру книги (в XML, JSON, ..) через запрос POST или PUT. Например, в XML структура книги выглядит следующим образом (упрощенно):

<book>
    <title>My Book</title>
    <author>John Q.</author>
</book>

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

Когда книга извлекается через GET, эти дополнительные свойства включаются в определение книги:

<book>
    <title>My Book</title>
    <author>John Q.</author>
    <info>
        <creation_date>2011...</creation_data>
        <user_id>48</user_id>
        <identifier>my_book_john_q</identifier>
    </info>
</book>

Это в основном означает, что схема XML новой / отредактированной книги (= от клиента к серверу) отличается от извлеченной книги (= от сервера к клиенту). Это сбивает с толку.

Можно сделать эти дополнительные свойства доступными в другом URI, например:

http://server/books/:id/             -> returns the short version
http://server/books/:id/information/ -> returns the generated properties

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

Как бы вы решили это несоответствие?

Answer 1

Это совершенно нормально.Нет проблем с тем, чтобы сервер дополнил представление некоторой дополнительной информацией.Хороший пример этого - когда сервер добавляет ссылки на представление.Клиенту не требуется отправлять «копии» этих ссылок на сервер при выполнении PUT.Представления ресурсов, которые вы получаете и PUT, должны быть концептуально одинаковыми, необязательно байты для байта идентичны.

Answer 2

Вы не правильно используете mimetypes. Могу поспорить, что вы используете application/xml универсальный mimetype, и ваши клиенты знают, чего ожидать в зависимости от конечной точки, верно?

Надлежащим способом решения вашей проблемы было бы иметь разные представления для одного и того же ресурса с разными миметипами. Например, у вас может быть application/vnd.yourcompany.book.short+xml для короткого представления и application/vnd.yourcompany.book+xml для полного представления. Клиенты могут использовать заголовок Content-Type, чтобы указать, какой из них отправляет, и заголовок Accept, чтобы указать, какой из них они хотят.

Это не означает, что клиенты должны отправлять короткие представления в POST или PUT. Вы можете задокументировать некоторые поля как необязательные, и клиенты могут их пропустить.