Фон

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

Текущий API

Рассмотрим API с двумя объектами, функциями и атрибутами.

Конечная точка функции — /api/featureи выглядит как:

{
    id: 5,
    name: "My super cool feature",
    geometry: {
        type: "Point",
        coordinates: [
            -88.043355345726,
            43.293055846667315
        ]
    }
}

Конечная точка атрибута — /api/attribute. Атрибут выглядит как:

{
    id: 3,
    feature_id: 5,
    name: "attr-name",
    value: "value"
}

Вы можете взаимодействовать с этими объектами, отправляя HTTP-запросы к их конечным точкам, используя различные методы HTTP, как и следовало ожидать :

• GET /api/feature/5. читает функцию с идентификатором 5.
• PUT /api/feature/5обновляет функцию с идентификатором 5.
• POST /api/featureсоздает новую функцию.
• DELETE /api/feature/5удаляет функцию с идентификатором 5.

То же самое касается атрибутов.

Атрибуты связаны с функциями по внешнему ключу (, обычно выражаемому как «функции имеют много атрибутов» ).

Проблема

Было бы полезно иметь возможность сделать копию объекта и всех его метаданных (всех атрибутов, которые ему принадлежат ). Вариант использования примерно такой: «Я только что сделал эту функцию и присвоил ей кучу атрибутов, теперь я хочу то же самое… но вот здесь». Таким образом, единственное различие между двумя функциями будет заключаться в их геометрии.

Решение #1 :Заставьте клиента сделать это.

Моей первой мыслью было просто попросить клиента сделать это. Создайте новый объект с тем же именем в новом месте, затем выполните итерацию по всем атрибутам исходного объекта, отправив POSTзапросы на создание их копий для нового объекта. Это, однако, страдает от нескольких проблем. Первый,это не атомарно. Если во время этого процесса интернет-соединение клиента прервется, у вас останется неполная копия, что неубедительно. Во-вторых, это, вероятно, будет медленным, особенно для функций со многими атрибутами. В любом случае, это плохая идея.

Решение #2 :Добавьте функцию копирования в API.

Выполнение серверной части копирования -в одном вызове API было бы лучшим подходом. Это приводит меня кhttp://tools.ietf.org/html/rfc2518#section-8.8и метод COPY. Возможность сделать глубокую копию функции в одном запросе COPY /api/feature/5кажется идеальной.

Вопрос

Моя проблема здесь в том, что семантика COPYне совсем соответствует тому использованию, которое я себе представляю. Выдача запроса COPYна ресурс выполняет копию этого ресурса в место назначения, указанное в заголовке Destination. Согласно RFC, Destinationдолжен присутствовать, и это должен быть URI, указывающий, где в конечном итоге окажется скопированный ресурс. В моем случае местом назначения для скопированного объекта является геометрия, которая определенно не является URI.

Итак, мои вопросы: :Будет ли вставка json для геометрии в заголовок Destinationзапроса COPYискажением спецификации? COPYвообще уместно здесь использовать? Если нет, то какие есть альтернативы? Я просто хочу быть уверен, что реализую это наиболее кошерным способом HTTP -.