Как вы справляетесь с динамическими ресурсами в контексте RESTful? - PullRequest
4 голосов
/ 07 мая 2009

Исходя из того, что я понимаю о принципах REST, URL-адреса должны представлять отдельный ресурс, например пользователя или продукт. Как вы имеете дело с ресурсами, которые являются случайными или генерируются динамически?

Предположим, я создаю ресурс api.example.com/integer, который возвращает случайное целое число. Буду ли я использовать GET для получения целого числа? Что означают POST, PUT и DELETE в этом контексте?

А как насчет URL, которые представляют поведение? Предположим, я создал ресурс под названием api.example.com/add, который возвращает сумму двух чисел. Если я хочу использовать этот ресурс, могу ли я использовать GET или POST для отправки чисел, которые будут добавлены?

Ответы [ 4 ]

7 голосов
/ 07 мая 2009

Не обязательно, чтобы все ресурсы поддерживали все глаголы. Вот для чего используется глагол ОПЦИИ, чтобы узнать, какие глаголы поддерживаются.

Я бы сказал, что одно из следующего довольно самоочевидно

GET http://api.example.org/RandomInteger

POST http://api.example.org/RandomNumberMachine

Либо может быть действительным. Просто будьте осторожны, чтобы GET-запрос мог кэшироваться. Если это произойдет, вы не получите случайный результат.

Один из основных принципов, лежащих в основе REST, заключается в том, что вы моделируете, что ваши URL-адреса представляют собой существительные, а не глаголы. Так что http://api.example.com/add не является идеальным URL.

Вы могли бы сделать

GET http://api.example.org/Summation?Values=2,4

или

POST http://api.example.org/AddingMachine

с телом объекта стандартного формата, содержащим числа для добавления.

На первый взгляд может показаться довольно педантичным различие между URL, оканчивающимся на «Добавить», и URL, оканчивающимся на «суммирование». Тем не менее, это довольно простой пример, и есть ограничение REST, которое поможет вам создать проект, имеющий определенные желательные характеристики для распределенных систем.

Много лет назад люди спорили о разнице между

apple.bite()

и

bite(apple)

не было значимым. Я не думаю, что слишком многие отклонят это различие в наши дни.

3 голосов
/ 07 мая 2009

Ресурс - это ресурс. Он может меняться, видоизменяться, переворачиваться вверх ногами или чем-то еще в течение своей жизни. Ваш ресурс в первом случае не случайное число, а случайное число генератор .

Как сказал Даррел, не обязательно, чтобы все данные ресурсы поддерживали все методы HTTP, чтобы быть RESTful. Черт возьми, у меня есть система RESTful, которая имеет различные ресурсы коллекций, которые позволяют GET (извлекать коллекцию) и POST (чтобы добавлять новый ресурс в коллекцию и, возможно, другие коллекции одновременно, что затем указывает на вновь созданную коллекцию. ресурс в другом месте), тогда как другие ресурсы поддерживают GET, PUT (для обновлений) и DELETE. Ключевым моментом в интерфейсе RESTful является то, что он универсально применим - т.е. методы протокола могут быть применены в общем виде ко многим различным видам ресурсов - который довольно универсально используется , что означает, что для реализации полного интерфейса потребуются все ресурсы.

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

В контексте HTTP, GET - прекрасный способ сделать что-то вроде вашего примера суммирования. Посмотрите на любую поисковую систему: все они используют GET для поиска, что совершенно НЕОБХОДИМО. Обратите внимание, что ваш браузер не имеет внеплановой информации о том, как создать URL ресурса, представляющего ваш поиск, но, загружая страницу, содержащую форму, он загружает инструкции о том, как это сделать. Это часть сущности HATEOAS и самоописания, с которыми вам придется столкнуться, когда вы узнаете больше.

3 голосов
/ 07 мая 2009

Я думаю, что GET подойдет для случайного числа. Вы бы просто не разрешили POST, PUT или DELETE для этого ресурса.

На сумму, почему бы просто:

getSum? Слагаемые = 3,5,8

Ответ - 16.

POST - это когда требуется, чтобы «исходный сервер принял сущность, заключенную в запросе, в качестве нового подчиненного ресурса, идентифицируемого идентификатором Request-URI в строке запроса.»

В этом случае серверу не нужно постоянно принимать / запоминать добавления, поэтому POST не подходит.

0 голосов
/ 21 июля 2009

Просто используйте какой-нибудь RPC. ОТДЫХ подходит не для всех целей.

...