Как раз никто и не хочет изобретать велосипед, идея REST (www.ics.uci.edu/...ation/rest_arch_style.htm) существует с момента создания HTTP. Посмотрите имя первого автора в списке — www.w3.org/...ocols/rfc2616/rfc2616.txt.

Но люди зачем-то упорно изобретают велосипеды, которые абсолютно не приспособлены к работе на века.

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

А если действие скажем по переводу денег доступно, но скажем не больше 10 баксов, а клиент пытается перевести 20? Можно конечно попытаться провернуть операцию и получить отказ от сервера, но тогда зачем создавать список доступных функций. Так же есть вариант бизнес правила, что деньги можно переводить, только если на счету не меньше 100 баксов, наверняка клиент попросит втулить задисейбленную кнопку с надписью, что вам не хватает денег на счету и пополните его плиз, сразу возникает вопрос, как в апи это будет выглядеть и как после пополнения клиент поймет, что теперь ему можно переводить деньги ? (из предположения, что все через апи и страничку мы не перегружаем)

Начну с конца, в крайнем случае в REST есть code-on-demand, то есть сервер может отдавать в виде кода, например, конкретно условие проверки. И есть более развитые форматы, чем просто список ссылок, например, github.com/kevinswiber/siren, которые могут включать ваш случай.

Тут ключевой момент, заключается в том, чтобы желательно клиент как можно чаще обновлял «состояние» или, вообще, его не хранил (состояние кэша контролируемое сервером — норм.).

Как один из вариантов реализации я бы отдать клиенту не только перечень ссылок, но и перечень недоступных действий с причинами. Здесь самое важное сохранить масштабируемость с точки зрения функциональности, не перенося бизнес-логику на клиент.

Спасибо за интересные вопросы. Именно, таких я и ждал.

Похоже на WSDL.

Как я понимаю WSDL — это статический перечень возможных действий. В HATEOAS же, мы получаем его динамически, при каждом запросе.

Это еще можно представить себе так:

1. Вы зная термин, сразу вводите адрес нужной страницы в Википедии (RPC);
2. Вы бороздите просторы Википедии только по доступным вам ссылкам, которые определяются динамически (HATEOAS).

У меня не всегда получается вычислить все возможные действия и некоторые из них я отдаю с представлением ресурса всегда. Получается, что в крайнем случае, такой список может выродиться в статический.

Можно с примером ?

Приведу пример близкий к моей текущей работе.

Допустим, что наше приложение редактирует презентацию — Google Slides. И допустим, что там мы открываем презентацию в которой 200 слайдов. У презентации есть свойства, есть также коллекция слайдов и у слайдов есть содержимое и свойства. И вот перед нами стоит задача спроектировать API для открытия такой презентации и прорисовки дерева со слайдами и для, допустим, редактирования содержимого слайда. Есть множество вариантов, как здесь смоделировать ресурсы. Рассмотрим пару вариантов:

1. Отдаем все одним запросом;
2. Отдаем презентацию и в ней коллекцию с представлением слайда, достаточным для отрисовки дерева. При клике на слайд, подгружаем представление слайда и список возможных действий над ним.

Все зависит от того, как ваше приложение, кто, с какой частотой и т. д.

По 1-ому варианту. Если вы загрузите все представление ресурса одним запросом, то это означает, что у вас на клиенте появиться «состояние» ресурса, за которым вам нужно будет следить. Если у вас с презентацией может работать только один пользователь, вы не используете HATEOAS и у вас вся логика на клиенте, то такое вполне допустимо. Вы, правда, все равно ресурс будет обновлять «порциями», а не целиком. Я бы не называл такой подход — REST-подходом, но опять же, при определенных условиях приемлемо.

Во 2-ом варианте, у вас на клиенте практически нет состояния, вы каждый раз обновляете его, посылая запрос на сервер и получаете список возможных действий. Например, что слайд, этот слайд можно скопировать, а другой нет. Здесь, появляется простота в масштабировании с точки зрения функциональности, есть всего лишь одно место для внесения изменений в бизнес-логике — это север.

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

И да, и нет.

Есть такая модель — martinfowler.com/...hardsonMaturityModel.html. По ней, да, RPC — это первые уровни REST.

Реализации SOAP, которые я видел — это практически RPC и бонусы протокола.

Я бы хотел, чтобы все что не реализует HATEOAS, не называлось REST. Рой похоже об этом и говорит — roy.gbiv.com/...-must-be-hypertext-driven.

Я очень поверхностно знаком с SOAP и лишь немного с ним работал на практике. Поэтому не возьмусь судить о преимуществах.

У такому вигляді як ви описали я РЕСТ не зустрічав.

Именно поэтому я решил попробовать со статьей, ибо то, что я вижу — это, в подавляющем большинстве, RPC.

Сейчас и работаю над такой версией API, где у нас есть список возможных действий, которые отдаются клиенту. Это позволяет нам делать интересные вещи:

• Клиент не содержит бизнес-логики. Если действие доступно, например, снять деньги со счета, то он рисует соответствующую кнопку и не хранит у себя выражения вроде “if (account.balance.amount > 0)”. А что если завтра эти правила поменяются?
• Независимость от URL. Клиент по-просту о них не знает, у него есть только entry point и не более. Это позволяет менять нам URL как угодно и на что угодно. Например, разобьем приложение на микросервисы, а клиент даже не узнает о том, что шлет запросы на другой URL. (CORS настроим, если речь о клиенте в браузере).
• Разбиваем ресурсы на “под-ресурсы”. Например, вместо того, чтобы отдавать один большой ресурс, мы можем изучить запросы пользователи и разбить на “под-ресурсы” все так, что ресурсы сервера будут утилизироваться максимально эффективно.
• И другие.

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

Что касается реальных примеров, то есть положительная тенденция. Github API, Twitter API и другие гиганты уже как минимум отдают ссылки на ресурсы, многие из них уже отдают ссылки на возможные действия.

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

К примеру, здесь — парень рассказывает, что они делали подобное для DHL и показывает пример на практике.

Спасибо за ваш комментарий. Заставили меня задуматься. Я действительно где-то перегнул палку, осознанно или нет. Извините, если может и оскорбил где.

Для меня важно было понять с какой позиции вы говорите о TDD. Именно потому, что:

вокруг и так слишком мало думающих людей

Очень сложно понять, человек действительно понимает о чем говорит и у нас разбирался в этом вопросе или же он просто повторяет «прочитанное где-нибудь».

Позже, если появится возможность, еще раз перечитаю ваши комментарии и попробую ответить аргументированно.

Даже представить себе не можете на сколько ваш комментарий был предсказуем.

Уже задолбали, перечитайте вопрос в теме. Этот топик только для последователей секты TDD/BDD, если вы не практикуете, то зачем ломитесь навязывать свое единственно-правильное мнение.

Мыслите шире, ретроспектива — широкий термин означающий «взгляд назад» и мне абсолютно пох..й на всякие ваши там аджайл и скрам. Я даже толком не знаю, что это.

Очнитесь! Применять нужно только то, что работает и позволяет решать задачу эффективно. Нужно быть рациональным, а не темным средневековым человечком. Не работает у вас TDD? Так и не применяйте, работайте так как получается. Главное, что вы решаете поставленные перед вами задачи.

Не правы. А почему неправы — поймёте, когда перестанете вещать из позы... и осмыслите, что я писал в соседних комментариях и темах

Вам самому не стыдно? Что вы пишете, бл..ть? Позиция типа, я написал очень умную ху..тень, а ты дебил не понял иди и перечитывай, пока не просветлишься.

Я с таким же успехом могу написать, что перечитывайте мои комментарии, раз нихера не поняли.

Я несколько прочитал ваши комментарии и понял, что вы не знаете ответа на вопрос: «Почему нужно писать тесты сначала?»

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

Почему я решил, что вы не можете допустить, что вы глупы и наивны?

Мы достаточно просветлены: TDD не нужен.

У вас не работает TDD/BDD, так и не используйте. Все очень просто. Еще раз повторюсь и вы сами это знаете, используйте только то, что подходит именно вам. Нах..р приходить сюда и навязывать мнение, что TDD/BDD плох. Люди же увидят у вас в профиле должность и могут поверить вам. Это очень опасно.

У вас есть шанс исправиться и признаться, что вы не понимаете и не умеете TDD/BDD. В этом нет ничего страшного.

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

Вообще, статическая типизация, в том числе и схемы — это нечто, в моем мировоззрении — лучше тестов.

Это точка зрения.

Да, использовал множества, пересечения и триангуляцию для решения поставленной задачи.

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

Я с таким же успехом могу сказать о вас: «Вот мышление антагониста TDD: стохастичность и метод Монте-Карло» (хуяк-хуяк и в продакшн). Лан. шучу, тут я конечно злонамеренно.

Но все равно спасибо, подумаю, может и вправду мыслю шаблонами.

Хм, как бы сделать вашим комментарий лучшим? =)) Самый лучший ответ на вопрос который я и задал в этом топике.

«Тест сначала» — формальная постановка задачи с возможностью быстро проверить в любой момент, а решена ли она.

Был сарказм, абы ляпнуть.

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

Я junior coding monkey и мне TDD нужен для моей же дисциплины и для вправки мозгов.

Тесты — это такой же код. Их суть — автоматизация рутиных проверок. Подчёркиваю — рутиных. До тех пор пока код пишется, пока логика не реализована — все проверки свежие.

Вы автоматизируете рутинные проверки потому, что в этом и видите суть тестов.

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

Как знать что является поводом выбросить нормальное исключение, а что — бага, до тех пор пока код не написан?

Тест до написания кода — это спецификация. Вот вам пример для Java jetbrains.github.io/spek

-200. Или не проверяли на практике, или же у вас качество организации процесса ниже плинтуса.

Могу ошибаться и не воспринимайте как на личное, мне действительно интересно понять вас.

Похоже, что вы не понимаете зачем нужен TDD/BDD и не понимаете как это работает.

Поправьте, если я не прав, но уверен, что вы пытались применить данный подход и у вас просто не получилось. Но вместо проведения ретроспективы, вы просто решили, что TDD/BDD по-просту полная ху..та, так как если вы с этим не справились и вы не смогли принять факт, что вам, возможно, могло не хватить ума.

Не апеллируйте на основе своего N-летнего опыта, он вам тут больше мешает.

Что дает вам право решать какие практики хорошие, а какие — нет?

Да, я решил, что TDD — хорошая практика. Вот просто так, от фонаря. Что по вашему мне может запретить или дать такое право?

Я уверен, найдется over 100500 отличных продуктов написанных без применения TDD, и единицы (почему-то о них тут вообще не упомянуто) с ним.

Согласен, вообще, не оспаривается. Независимо от того, что TDD хорошая практика (решено лично мной без всякого права), ясный пень, что эта практика не гарантирует отличный продукт, которым будут пользоваться и который будет популярен. Все зависит от мозгов применяющего.

Если большинство комментирующих не встречалось с этим — это не значит, что этого нет.

Допустим вы проводите собеседование с человеком и от вас зависит возьмут его или нет, то ваши действия в случаях:

1. Вы кого возьмете: лучшего друга или хорошего специалиста?
2. Украинца или индуса?

Не отвечайте мне в комментариях, ответьте на этот вопрос себе. Только ответьте честно, а не «правильным» ответом.

Автор, у меня было похожее чувство, когда я хотел пойти в NetCracker:

dou.ua/...cracker/#143628
dou.ua/...cracker/#143636
dou.ua/...cracker/#143776

Дело было точно не в кумовстве. Но истинную причину мне так, никто и не сказал. А я хотел ее узнать, о поверьте как хотел. Я тогда был высокого о себе мнения, отлично щелкал задачки, много читал, много программировал. И тут мне отказали, а других ребят, которых я считал слабее себя и все это подтверждали, даже сами ребята — их взяли.

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

Возможно, меня не взяли потому, что я говорил прямо, как есть: «Хочу быть программистом, а потом менеджером и зарабатывать очень много.» Нафиг им такой программист? Просто я не уточнял, что менеджером хочу быть не раньше 25 лет. А сейчас и вовсе другого мнения.

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

Тим, перестаньте =) Я не настолько наивен.

Те темы, которые вы описали. в них спокойно можно применять TDD, пусть даже не TDD, а хотя бы тесты:

1. Mobile: на оф. сайте Anroid developer.android.com/...it-testing.html
2. Gamedev, как один из самых популярных примеров unity3d.com/...hive/test-tools
3. OS/drivers здесь вообще в первую очередь, у меня знакомая пишет софт для Automotive, для железа и прекрасно там у них работает тестирование и это из самых важных моментов.
4. ...

Может вы просто не представляете себе, как там можно это применить? =))

Я же не в вакууме живу и общаюсь с людьми, знаю, кто применяет, кто нет. Чаще всего знаю почему. Я эту тему открывал для тех, кто практикует TDD. Я же как раз сужал аудиторию отвечающих. Перечитайте. Я спросил: «Вы пишите тесты до/после и почему?» Не более.

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

Ребята, это 100% не рекламная кампания. Здесь dou.ua/add-post написано, что рекламу не размещают. Если бы автор участвовал в комментариях и не был бы менеджером по продажам, то да реклама, а так нет ;)

Идея классная, не первые в мире, но идея классная. Всегда мечтал создать нечто подобное =) Чтобы Интернет-магазин сам в итоге подгонял цены для разных покупателей, в разное время, сам как-то проводил оптимизацию и т. д. Ведь вашему клиенту не нужны все эти сложные графики, все эти подсказки и т. д. Сами же пишите, что ему нужны деньги. Клиент просто хочет прийти, установить «скриптик» (интегрироваться с вами) и чтобы у него просто росла прибыль.

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

Абсолютно с вами согласен.

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

Вот, например, вакансия с TDD/BDD jobs.dou.ua/...vacancies/4443 я бы пошел сюда пособеседоваться, но не из-за TDD. Или здесь jobs.dou.ua/...acancies/10540.

Вот, вроде интересная jobs.dou.ua/...acancies/12630, но нет TDD. Но я бы не пошел туда по-другим причинам.

Мы ищем ту работу, которую подходит нам по критериям. И если кто-то ходил на собеседования и там не было речи о TDD — это тоже абсолютно не значит, что это не стандарт де факто и что этого нигде нет.