RESTful - можно ли передавать данные в параметрах

REST: запрос баланса

GET http://api.bank/balanse/user/today ==> баланс

GET http://api.bank/transaction/user/2016-02-15?sum=25 ==> id, статус

Не REST - пытаться вызвать на сервере функции

get-balanse(user, today)

(setf (options user) :disabled)

Желание json и xml для дискретных входных параметов - это что-то странное применительно к REST.

А что, если я передаю в параметре put, то это уже не RESTful?

PUT и POST имеют большую разницу. Возьмем тот же RESTful на примере ES.

1. Нужно отправить запрос на закрытие индекса, но передавать ничего не нужно, т.к. исходя из концепции RESTful - сам запрос может содержать в себе и команду (в простом виде, конечно же). Используем POST.

   curl -XPOST http://localhost:9200/testindex/_close

2. Нужно перезалить конфигу (она может быть огромной), что использовать? Ну не параметры же... Конечно, PUT.

   curl -XPUT http://localhost:9200/testindex/_settings -d {large_object: many_many_fields...}

Советую почитать Best practices for designing a pragmatic RESTful API, там довольно хорошо освещена сама концепция RESTful.

провести сделку

GET http://api.bank/transaction/user/2016-02-15?sum=25 ==> id, статус

GET'ом проводить сделки НЕ СЛЕДУЕТ, так как подразумевается, что он не сделает ничего более существенного, чем просто выберет и вернёт данные (9.1.1). Вдобавок он является идемпотентным (9.1.2). Как и PUT, кстати говоря, так что им сделки тоже НЕ СЛЕДУЕТ проводить, разве что вы хотите, чтобы из десяти отправленных подряд одинаковых сделок прошла только одна.

А вы не заметили изначально не Ъ-подобную проектировку связи ресурсов? То, что там написано - это ведь совсем не RESTful :) Т.е.:

GET http://api.bank/balanse(ресурс)/user(ресурс)

GET http://v.api.some/some_resource/some_id/linked_resource/

Нужно отправить запрос на закрытие индекса, но передавать ничего не нужно, т.к. исходя из концепции RESTful - сам запрос может содержать в себе и команду (в простом виде, конечно же). Используем POST.

curl -XPOST http://localhost:9200/testindex/_close

Не соглашусь. POST используется, чтобы сервер, используя переданное нами состояние, создал у указанного нами ресурса новый подресурс. Что из себя представляет ресурс _close? Что за ребёнок будет у него создан в данном случае?

Я считаю, что в конкретном примере правильнее использовать PUT или PATCH в http://localhost:9200/testindex, передавая туда желаемое состояние. А через тело или через аргументы - это уже от данных зависит: ?closed=True или {'state': 'closed'} или что там ещё.

Да, конечно, но я хотел в первую очередь обратить внимание на GET - его для таких целей использовать нельзя. Например, браузер или любая промежуточная прокся могут закешировать ответ (и будут правы), и мы никогда не узнаем о том, что наши распоряжения не доходят до адресата.

Да, вы правы, ES применяет не совсем точный подход RESTful, но здесь проблема только в терминологии. То есть внутри ES ресурсы подразделяются на команды, и непосредственно ресурсы. Команды определяются как раз наличием _ у имени. То есть _close/_open/_some_command. Поэтому для запроса команд используется в основном POST метод. Думаю что проектировщики изначально из этого принципа и выходили.

т.к. исходя из концепции RESTful - сам запрос может содержать в себе и команду

Хотя да, это не совсем по Филдингу, но, опять же, в моем понимании Филдинг описывает REST как что-то куда более масштабное, нежели простое применение в HTTP.

Честно говоря, не знаю, что такое ES, но тем не менее.

То есть внутри ES ресурсы подразделяются на команды, и непосредственно ресурсы. Команды определяются как раз наличием _ у имени. То есть _close/_open/_some_command. Поэтому для запроса команд используется в основном POST метод. Думаю что проектировщики изначально из этого принципа и выходили.

В принципе, если немного пофантазировать, можно представить POST в _some_command как выпуск некоего «приказа» на выполнение этой команды. Возможно даже, в ответ придёт некий id, по которому можно отслеживать процесс его выполнения. В такой интерпретации всё очень даже RESTful.

Хотя да, это не совсем по Филдингу, но, опять же, в моем понимании Филдинг описывает REST как что-то куда более масштабное, нежели простое применение в HTTP.

Есть такое. Он там, может, межгалактический Web5.0 уже придумывает, но мы-то пока на Земле копошимся, так что будем решать задачи в меру своего разумения. С другой стороны, REST - не набор абсолютных правил и догм, а стиль проектирования, отступать от которого не является преступлением. И если для какой-то проблемы есть красивое, но не стильное (читай не RESTful) решение, я лично предпочту его, нежели стильное, но уродливое.

Честно говоря, не знаю, что такое ES, но тем не менее.

ElasticSearch, добротный поисковый движок-обертка над Lucene Apache, написанный на Java. Оставлю ссыль, вдруг когда-нибудь пригодится.

И если для какой-то проблемы есть красивое, но не стильное (читай не RESTful) решение, я лично предпочту его, нежели стильное, но уродливое.

Согласен с вами.

а способ передачи параметра не имеет значения.

Совершенно верно, REST не определяет формат данных.

Плюсую.

Браузер всегда руководствуется рекомендациями веб-сервера. Он не станет по велению левой пятки кешировать.

Всем спасибо! Буду пользоваться параметрами!

На всякий случай, вот что я читал по теме:

http://stackoverflow.com/questions/3105296/if-rest-applications-are-supposed-...

Архитектура REST

Что такое RESTful на самом деле