LINUX.ORG.RU

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

 ,


1

3

У гугла уже спрашивал.

Делаю PUT (или POST). Где-то в интернетах пишут, что RESTful подразумевает передачу данных в виде json или XML.

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

А что, если я передаю в параметре put, то это уже не 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.

antares0 ★★★ ()

А что, если я передаю в параметре 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.

znenyegvkby ()
Ответ на: комментарий от antares0

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

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



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

Laz ★★★★★ ()
Ответ на: комментарий от Laz

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

GET http://api.bank/balanse(ресурс)/user(ресурс)
Вместо каноничного
GET http://v.api.some/some_resource/some_id/linked_resource/
Я думаю все беды в кривом RESTful от нежелания воспринимать его модель как абстрактный автомат. То есть состояние - изменение состояния в определенный момент времени, и, аналогично, возврат состояния. Больше ничего. Но многие при проектировании API забывают об этом, потому и получаются ужасные монстры.

znenyegvkby ()
Ответ на: комментарий от znenyegvkby

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

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



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

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

Laz ★★★★★ ()
Ответ на: комментарий от znenyegvkby

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

Laz ★★★★★ ()
Ответ на: комментарий от Laz

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

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

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

znenyegvkby ()
Ответ на: комментарий от znenyegvkby

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

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

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

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

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

Laz ★★★★★ ()
Ответ на: комментарий от Laz

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

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

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

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

znenyegvkby ()

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

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

Hater ★★ ()
Ответ на: комментарий от Laz

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

Hater ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.