Что такое краткий способ понять RESTful и его последствия?

Question

** обновление: ужас! так что это путешествие практики и понимания. ;) Теперь я больше не чувствую себя настолько глупым. *

Я прочитал много статей о REST и написал несколько приложений для rails, которые используют ресурсы RESTful. Однако я никогда не чувствовал, что полностью понимаю, что это такое, и в чем разница между RESTful и non-restful. Мне также трудно объяснить людям, почему / когда им следует это использовать.

Если есть кто-то, кто нашел очень четкое объяснение для REST и обстоятельств, когда / почему / где его использовать, (а когда нет), это принесет пользу миру, если вы сможете это поднять, спасибо! =)

Answer 1

REST обычно изучается так:

1. Вы слышали о том, что REST использует HTTP так, как он должен был использоваться , и из-за этого вы избегаете конвертов SOAP Web Services, так как большая часть того, что требуется многими стандартами SOAP, обрабатывается HTTP в простой, не глупый способ. Вы также быстро узнаете, что вам нужно использовать правильный метод для правильной операции .
2. Позже, возможно, спустя годы, вы слышите, что REST - это больше, чем . REST на самом деле также является концепцией связи между ресурсами . Это часто занимает некоторое время, чтобы понять полное значение, но когда вы изучаете это, вы начинаете вводить гиперссылки в свои ответы, чтобы клиенты могли перемещаться по вашей системе, не будучи привязанными к тому, как сервер хочет назвать свои ресурсы (то есть URI).
3. Даже позже вы узнаете, что вы все еще не поняли REST! И это потому, что вы обнаружите, что типы носителей важны . Вы начинаете создавать медиа-типы с именем application/vnd.example.foo+json и вставляете в них гиперссылки, поскольку это уже ваше понимание REST.
4. Проходят годы, и вы в сотый раз перечитываете тезис Филдинга, чтобы увидеть, пропустили ли вы что-нибудь, и вдруг до вас доходит, что действительно ограничение HATEOAS: речь идет не о клиенте иметь представление о том, как структурированы ресурсы сервера, но обнаруживает эти отношения во время выполнения. Это также означает, что экран перед пользователем полностью управляется тем, что передается по проводам , так что на самом деле, если сервер передает изображение / jpeg, то это то, что вы должны показать пользователь, а не сообщение об ошибке «AtomProcessor не может обработать изображение / JPEG».

Я просто смирился с # 4 и надеюсь, что лестница не намного дольше! Это заняло у меня семь лет.

Answer 2

Эта статья хорошо справляется с классификацией различий в нескольких стилях приложений http от WS- * до чистоты RESTian.Что мне нравится в этом посте, так это то, что он напоминает вам о том, что большая часть того, что мы называем REST, действительно лишь частично соответствует первоначальному определению Роя Филдинга.

В InfoQ есть целый раздел , посвященный большей частиугол «что такое REST».

С точки зрения REST против SOAP, этот вопрос , по-видимому, имеет ряд хороших ответов, особенно выбранный ответ.

Answer 3

Масштабируемость является очевидным преимуществом REST (без сохранения состояния, кэширование).

Но также - и это, вероятно, главное преимущество гипертекста - REST идеально подходит для тех случаев, когда к вашим услугам большое количество клиентов.Следование REST и ограничение гипертекста радикально уменьшает связь между всеми этими клиентами и вашим сервером, что означает, что у вас больше свободы при развитии / развитии вашего сервиса с течением времени - вы не связаны с риском разорвать потенциальных клиентов.

С практической точки зрения, если вы работаете с rails - restfulie - отличная небольшая платформа для работы с гипертекстом на клиенте и сервере.Серверная часть является расширением rails, а клиент - DSL для обработки изменений состояния.Интересные вещи, проверьте это здесь: http://restfulie.caelum.com.br/ - Я очень рекомендую учебник / демонстрационные видеоролики, которые они имеют на vimeo:)

Answer 4

Я бы представил YMMV, но мне было очень легко начать понимать детали REST после того, как я понял, что REST по сути является продолжением статических концепций WWW в пространстве дизайна веб-приложений. Я написал (довольно длинный) пост на том же: Почему REST?

Answer 5

Content-Type: text / x-flamebait

В последнее время я задавал тот же вопрос, и я полагаю, что половина проблемы заключается в объяснении того, почему полноценный REST полезен при определенииИнтерфейс для машинно-потребляемых данных является тем, что большую часть времени это не так.Хорошо, вам нужна действительно веская причина, чтобы игнорировать биты здравого смысла (URL-адреса определяют ресурсы, HTTP-глаголы определяют действия и т. Д. И т. Д.) - я ни в коем случае не предлагаю вернуться к мерзости, которая была SOAP.Но выполнение HATEOAS способом, одобренным Fielding (без нестандартных типов носителей) и дружественным к машине, похоже, дает убывающую отдачу: все это очень хорошо, используя стандартный тип носителя для описания допустимых переходов (если такой тип носителя)существует), но если приложение вообще сложно, агент вашего потребителя все еще должен знать, какие правильные переходы нужно сделать для достижения желаемой цели (покупка билета или что-то еще), и он не может этого сделать, если ваш потребитель (человек) это говорит.И если ему необходимо встроить в свою программу внеполосное знание о том, что путь с linkrels create_order => add_line => add_payment_info => Подтверждение является правильным, а reset_order не является правильным путем, то я не вижучто это гораздо более тяжкий грех - заставить его учить свой XML-парсер, что делать с application / x-vnd.yourname.order.

Я имею в виду, очевидно, да это все меньше работыокруглите, если есть подходящий стандартный формат с библиотеками и еще много чего, что можно использовать повторно, но в (возможно, более распространенном) случае этого нет, ваши варианты в соответствии с Fielding-REST: (а) создать стандарт или (б)увеличить клиент, загрузив код в него.Если вы просто хотите выполнить свою работу, а не изменить мир, вариант (с) «просто что-то придумать», вероятно, выглядит довольно заманчивым, и я, например, не стал бы винить вас за то, что вы взяли ее.