Что лучше: возврат объекта Response или объекта, представляющего ресурс остатка?

В некоторых книгах, как API, остальные обычно возвращает объект ответа, который оборачивает некоторые другие объекты, представляющие полезную нагрузку, состояние и т.д.Что лучше: возврат объекта Response или объекта, представляющего ресурс остатка?

С другой стороны, многими из API, которые я видел и написал возвращающую POJO (или вызов это DTO) как JSON, который потребляется клиентом.

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

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

Спасибо.

Обновление: Два API-интерфейса останова будут выглядеть следующим образом. Как избежать такой код @Path, @Get, @PathParam, @Produces и т.д.

public Response myCustomerObject(int id){...}

Это возвращает объект клиента, обернутый внутри объекта Response. Ответ также может быть ошибкой.

И подход ниже будет возвращать объект клиента непосредственно:

public Customer myCustomerObject(int id){...}

источник

2015-07-08 Atul

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

REST-API не имеют ничего общего с конкретной реализацией какой-либо структуры, которую вы используете, особенно если вы используете объект Response против POJO. POJO будет сопоставлен с желаемым форматом вывода, понятным клиенту (заголовок Accept), с помощью базовой структуры и возвращает код ответа по умолчанию (если это не указано в аннотации или исключение (обработчики) в противном случае). Объект Response задает код возврата, и объект возвращается явно, хотя маршаллинг также может выполняться автоматически. –

@AlbertoZaccagni добавит пример. – Atul

Я бы голосовать за API, который дает вам объект Response. Это позволяет полностью контролировать ответ в вашем коде, и ясно, что происходит в ответ. И в тех случаях, когда вы хотите написать ответ, который не может быть легко представлен POJO, вы не будете вынуждены использовать неинтуитивные обходные пути.

Возврат объекта из метода обработчика покоя, который затем преобразуется в ответ, слишком много магии рамки для моего вкуса.

Худший - имхо - это практика возвращения строки из метода остаточного обработчика, который затем интерпретируется как ссылка на шаблон (например, путь к ресурсу JSP), который затем записывается в ответ. Опять слишком много магии.

источник

2015-07-08 13:37:28 wero

Я согласен с вами. Хотел знать, что такое передовая практика в отрасли. – Atul

плохой - хуже - хуже. Когда английские прилагательные имеют сравнительное склонение (и вы используете его, например, хуже), вы не используете с ним «больше». «Хуже» - неудобно. – scottb

Тот возвращался объект ответа содержит ваши данные получают наследство запроса/ответ услуг, как SOAP и HTTP, но REST службы строить на концепции ресурсов не запроса/ответа поэтому я предпочитаю использовать объекты представляет фактическое значение ресурсы без оболочки, как служба отдыха может представлять ваши ресурсы напрямую на объект ответа для ex. если вы звоните ресурс как автомобиль:

http://localhost/car GET для списка автомобилей

http://localhost/car/1 GET для получения автомобиля с идентификатором 1

как представить это в объект ответа?

источник

2015-07-08 13:46:18

В JAX-RS вы аннотировали методы с f.e. '@Path ("/car ")' или '@Path ("/car/{id} "), который поэтому вызовет соответствующий метод, который может вернуть значение Response.status (Response.Status.OK). ..). build() 'instance, где конкретный объект либо сортируется вами, либо сортируется каркасом при передаче POJO как объекта. –

Я имею в виду, что если вы возвращаете объект ответа, который содержит ваши данные ответа, не будет синхронизироваться с концепцией обслуживания отдыха, которая ожидает список автомобилей в случае, если «/ автомобиль» и один автомобиль в случае «/ car/{ id} ", но если вы используете запрос/ответ, получите ответную оболочку в 2 случаях –

Я предпочитаю возвращать пользовательские объекты данных, а не объекты ответа. Весь смысл основанных на аннотациях фреймворков заключается в абстрагировании аспектов http из логики приложения. Вместо того, чтобы управлять кодами ответов и сущностями, разработчики приложений возвращают объекты модели и бросают пользовательские исключения, которые могут быть сопоставлены с http-кодами в mapper. Это меньше контроля, но имхо легче ускорить разработку api.

источник

2015-07-09 02:16:13 toadzky

Что лучше: возврат объекта Response или объекта, представляющего ресурс остатка?

ответ

Смежные вопросы