inossidabile Jan 2 2012 at 15:06

SOAP-сервер на Rails 3.x (WashOut)

2 min

5.6K

Round Lake corporate blog

+13

Comments 14

Alerticus Jan 2 2012 at 19:16

На мой взгляд, было бы неплохо в качестве значений для :args и :return принимать имя класса, в котором каким-либо образом описаны эти параметры. При запросе, например, из params создавать объект класса, указанного в :args, а при ответе принимать объект класса, указанного в :return.

inossidabile Jan 2 2012 at 19:29

Чтобы держать в нем обработку этих параметров? Имхо, это не самым лучшим образом скажется на MVC. Если нужна пред-обработка, есть before_filter. А для собственно действий, связки модели и контроллера должно хватить. Из менее теоретических минусов – не такая прямая совместимость с обычными HTTP-запросами.

А есть какой-нибудь живой кейс над которым можно подумать?

Alerticus Jan 2 2012 at 19:43

По-моему, очень даже хорошо скажется на MVC :) Иначе слишком много логики в контроллере для банального CRUD'а.

soap_action "AddCircle",
  :args   => Circle,
  :return => DefaultResponse,
  :to     => :add_circle

def add_circle
  circle = params[:circle]  # already Circle instance
  response = DefaultResponse.new
  unless circle.save
    response.errors = circle.errors
  end

  render :soap => response
end

Alerticus Jan 2 2012 at 19:52

Хотя нет, вот это не совместимо, если метод мультипротокольный, так что:

circle = params[:circle]  # already Circle instance

circle = Circle.new(params[:circle])

inossidabile Jan 2 2012 at 19:53

Если Circle.new, то зачем вам описывать это в soap_action? У вас получился обычный класс, который к библиотеке вроде отношения не имеет :).

Alerticus Jan 2 2012 at 20:11

Да, это к теме не относилось. А указывать класс, чтобы получить из него WSD, а не описывать заново.

inossidabile Jan 2 2012 at 19:52

Я всмысле не пример внешнего интерфейса, а пример живой потребности. Класс Circle (который, кстати, по этой логике должен в итоге содержаться прямо в params, а не params[:circle]) что делает? Просто хранит в себе данные или еще и как-то обрабатывает?

Если хранит, то, способ описывать сложные (и повторяющиеся) сущности в :args и :return действительно нужен. Сейчас это можно сделать через вынесение части хэша в переменные и это не удобно. Мы думаем над правильным интерфейсом для этого.

Нужен ли способ декорировать параметры – вопрос. Ни разу с такой потребностью не встречались. Это ведь совсем не SOAP-specific фича получается. Точно так же параметры передаются в REST (транспорт иной, суть та же), там ведь этого желания ни у кого не возникает? Для этой цели, вроде как, before_filter вполне достаточно.

Alerticus Jan 2 2012 at 20:04

Сейчас это можно сделать через вынесение части хэша в переменные и это не удобно

Вот про это я и говорю. Модель лучше знает, какие у неё геттеры / сеттеры и связи есть.

inossidabile Jan 2 2012 at 20:15

Только это не совсем модель. Проблема в том, что в реальной жизни SOAP нужен только там, где его нельзя избежать. А нельзя его избежать там, где сопрягаемый сервис писали люди, которые REST не любят (не знают/не могут). И поэтому SOAP-точка – это всегда жуткая мешанина с абстракцией предметного уровня сервиса, а совсем не CRUD. Приведение этой мешанины к данным, которые можно скормить моделям – совершенно точно задача контроллера, это позволит держать бизнес-логику кристально чистой, а всю гадость собрать в одном «проклятом и хорошо задокументированном месте».

На самом деле, то, о чем мы говорим – классический способ решения этой проблемы. Так делает тот же AWS. Имхо, это выглядит жутко коряво и сложно. Но если мы не найдем альтернатив в ближайшее время, так и сделаем :). В конце концов, пусть разработчик решает – где он хочет это держать. Это лишь мое мнение, что никуда этому из контроллера двигаться нельзя. Как известно: there is always more than one way to do it.

Так что мы мыслим примерно в одном направлении, спасибо.

painEffect Jan 3 2012 at 22:49

В AWS вроде предлагается использовать «глупые» структуры, и приводить модели к этим структурам программисту приходится где угодно. Я за «поумнение» структур до классов, соответствующих паттерну presenter. Как вам такая мысль?

inossidabile Jan 3 2012 at 22:55

По сути, мы как-раз к этому в диалоге с Alerticus и пришли. Модели тут вообще ни при чем, учитывая природу SOAP. А вот декораторы в добавок к описанию структуры – да, вполне звучит. Я не считаю это правильным, но библиотека такую возможность предоставлять наверное все-таки должна.

painEffect Jan 3 2012 at 23:05

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

inossidabile Jan 3 2012 at 23:17

Тут дело в том, что в SOAP обычно сущности не дублируются между сервисами, а следовательно между контроллерами. Номинально такое случиться может, но на практике я этого ни разу в жизни не встречал. Поэтому – да, номинально надоест. А на практике это передвигается в контроллеровый хэлпер и счастливо там живет.

В любом случае, как я и сказал, сделаем :). Тем более, что уже два голоса за.

whitequark Jan 3 2012 at 01:25

К сожалению, структура модели очень редко будет точно соответствовать структуре параметров SOAP-запроса — хотя бы пара полей да будут другими. А большая часть энтерпрайзных клиентов (вроде 1С и иже с ними) очень ревностно относится к неточностям в WSDL, выбрасывая ошибку при малейшем несоответствии.

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