Какова хорошая стратегия для добавления дополнительной информации в запросе GET через REST? - PullRequest
2 голосов
/ 09 марта 2011

Учитывая, что мы предоставляем успокоительный API, который обслуживает сущности книги, слушая в

/books

И клиент может получить книгу в обычном

GET /books/{id}

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

Таким образом, общий ответ может быть

 GET /books/4
 {"id":4, "price":"24.95"}

Где ответ на запрос скод скидки может быть

 GET /books/4
 {"id":4, "price":"24.95", "yourPrice":"19.95"}

Обработка на стороне сервера, которую мы можем выяснить, но какова лучшая практика для клиента, предоставляющего код скидки через API для отдыха?

На некоторые книги будут распространяться скидки, а на другие - нет.Скидки не будут широкими (20% от всего), но вместо этого будут привязаны к определенной цене для этого конкретного кода (или комбинации клиент / код).

Мы рассмотрели:

  • добавление URL-адреса

    GET / codes / {someCode} / books / {id}

  • Добавление кода в значение заголовка

  • Использование строки запроса

    GET / books? Code = myCode

  • что-нибудь еще?

РЕДАКТИРОВАТЬ : Наша цель - не внедрять одноразовые коды.Вместо этого эти коды скидок можно использовать для фиксированного набора книг некоторое фиксированное количество раз.

Ответы [ 4 ]

2 голосов
/ 09 марта 2011

Мне нравится использовать переменные запроса. Я только что посмотрел на книгу RESTful Web Services , мою основную ссылку в этой области, и они сказали:

Используйте переменные запроса только для предложения аргументы подключаются к алгоритм ... Если два URI отличаются только в их переменных запроса это подразумевает они разные наборы входов в тот же основной алгоритм.

Мне кажется, ваши коды скидок являются входными данными для алгоритма дисконтирования.

Charles

1 голос
/ 09 марта 2011

Все, что вы добавляете в значения URL или заголовка, открыто для перехвата и, возможно, позволяет другим пользователям «подделывать» свой идентификатор скидки. Один из подходов состоит в том, чтобы ввести новый вызов POST, который позволит зашифровать идентификатор с помощью простого HTTPS. Данные POSTed могут быть такими же простыми, как discountID или customerID.

Добавлено - Извините, Майкл, вы уже сказали, что:)

1 голос
/ 09 марта 2011

Если вы собираетесь отправлять что-либо, что не является идемпотентом, я бы предложил использовать POST вместо GET.Вы не хотели бы, чтобы клиент мог использовать свой код более одного раза.

0 голосов
/ 09 марта 2011

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

Пользователь может добавить код

POST /register/{code}

Это добавит запись в таблицу {user} - {code}, поэтому, когда пользователь получит

GET /books/{id}

будет использовать эту запись для применения скидки. Я предполагаю, что у вас уже есть какая-то связь между {code} - {book}, поэтому не буду вдаваться в подробности.

...