Как правильно передать дополнительный параметр в метод HTTP @DELETE - PullRequest
Новая
       27

Как правильно передать дополнительный параметр в метод HTTP @DELETE

0 голосов
/ 06 марта 2019

Мне нужно построить веб-сервис JAX-RS, который будет удалять клиента из клиентского ресурса, плюс у него должен быть внешний uuid в запросе.

реализация метода @DELETE без externalId очень проста 

/myService/client/1


@DELETE
    @Path("/client/{client}")
    public Response removeClient(@PathParam("client") long client) {

        // implementation code 

        return Response.status(200).build();
    }

но куда мне добавить externalId как @QueryParam?

в случае @QueryParam URI будет таким, это правильный дизайн?

/myService/client/1?externalId=d852e3fc-b7ac-42d7-b22b-74cb4da709ec

  @DELETE
        @Path("/client/{client}")
        public Response removeClient(@PathParam("client") long client, @QueryParam("externalId") String externalId ) {

            // implementation code 

            return Response.status(200).build();
        }

или, может быть, я должен отправить externalId в request body или как @PatchParam?

, что будет правильным дизайном?

мне следует использовать другой метод HTTPвместо HTTP DELETE для этого случая?

Ответы [ 2 ]

1 голос
/ 06 марта 2019

из спецификация:

Метод DELETE запрашивает, чтобы исходный сервер удалил ресурс, указанный в Request-URI.Этот метод МОЖЕТ быть отменен вмешательством человека (или другими средствами) на исходном сервере.Клиент не может быть гарантирован, что операция была выполнена, даже если код состояния, возвращенный с исходного сервера, указывает, что действие было успешно выполнено.Однако серверу НЕ СЛЕДУЕТ указывать успех, если только во время ответа он не намерен удалять ресурс или перемещать его в недоступное место.

Успешный ответ ДОЛЖЕН быть 200 (ОК), если ответвключает в себя объект, описывающий статус, 202 (принято), если действие еще не было выполнено, или 204 (нет содержимого), если действие было выполнено, но ответ не включает объект.

Если запроспроходит через кеш, а Request-URI идентифицирует одну или несколько кешируемых в данный момент сущностей, эти записи ДОЛЖНЫ рассматриваться как устаревшие.Ответы на этот метод не кешируются.

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

1 голос
/ 06 марта 2019

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

Добавление этой информации в тело?
Серверы могут игнорировать тело для запросов на удаление.

Суффиксирует эту информацию в пути?
Это нарушает семантику пути, который должен быть способом естественной идентификации ресурса в иерархии / структуре ресурса.

Я думаю, что вы действительно используете @QueryParam - приемлемый обходной путь, если у вас есть ограничение для передачи этих двух сведений, и что действительно вы не можете изменить его.
В качестве альтернативы вы также можете использовать параметры матрицы URL для передачи составного идентификатора
например DELETE /myService/client/1,123456, где 1 - идентификатор клиента, а 123456 - uuid

.
...