Что такое краткий способ понимания RESTful и его последствия?
** обновление: ужас! так что это путешествие практики и понимания. ;) теперь я больше не чувствую себя настолько глупым. *
Я прочитал много статей о REST и написал несколько приложений rails, которые используют ресурсы RESTful. Однако я никогда не чувствовал, что полностью понимаю, что это такое, и в чем разница между RESTful и non-restful. Мне также трудно объяснить людям, почему / когда им следует это использовать.
Если есть кто-то, кто нашел очень четкое объяснение для REST и обстоятельств, когда / почему / где его использовать (а когда нет), это принесло бы пользу миру, если бы вы могли это поднять, спасибо! =)
5 ответов
REST обычно изучается следующим образом:
- Вы слышали о том, что REST использует HTTP так, как он должен был использоваться , и поэтому избегаете веб-служб SOAP. 'конверты, поскольку большая часть того, что требуется для многих стандартов SOAP, обрабатывается HTTP простым и серьезным образом. Вы также быстро узнаете, что вам необходимо использовать правильный метод для правильной работы .
- Позже, возможно, годы спустя, вы услышите, что ОТДЫХ - это нечто большее . Фактически, REST также является концепцией связывания ресурсов . Часто требуется время, чтобы понять полное значение, но когда вы это узнаете, вы начинаете вводить гиперссылки в свои ответы, чтобы клиенты могли перемещаться по вашей системе, не будучи привязанными к тому, как сервер хочет называть свои ресурсы (то есть URI).
- Даже позже вы узнаете, что до сих пор не поняли REST! И это потому, что вы обнаруживаете, что типы носителей важны . Вы начинаете создавать типы носителей, называемые
application / vnd.example.foo + json, и помещаете в них гиперссылки, поскольку это уже ваше понимание REST. - Проходят годы, и вы в который раз перечитываете тезис Филдинга, чтобы увидеть, есть ли что-нибудь, что вы пропустили, и внезапно вы понимаете, что на самом деле ограничение HATEOAS заключается в следующем: это касается клиента, а не имея какое-либо представление о том, как структурированы ресурсы сервера, но обнаруживает эти отношения во время выполнения. Это также означает, что экран перед пользователем полностью управляется тем, что передается по сети , поэтому на самом деле, если сервер передает изображение / jpeg, то это то, что вы должны показать пользователь, а не сообщение об ошибке «AtomProcessor не может обрабатывать изображение / jpeg».
Я только начинаю смиряться с №4 и надеюсь, что лестница ненадолго! На это у меня ушло семь лет.
Масштабируемость - очевидное преимущество REST (без сохранения состояния, кэширование).
Но также - и это, вероятно, главное преимущество гипертекста - REST идеально подходит для случаев, когда у вас много клиентов. Следование REST и ограничению гипертекста резко снижает взаимосвязь между всеми этими клиентами и вашим сервером, что означает, что у вас больше свободы при развитии / развитии вашего сервиса с течением времени - вы не связаны риском поломки потенциальных связанных клиентов.
С практической точки зрения, если вы работаете с рельсами, то restfulie - отличный небольшой фреймворк для работы с гипертекстом на клиенте и сервере. Сторона сервера - это расширение рельсов, а клиент - это DSL для обработки изменений состояния. Интересный материал, посмотрите здесь: http://restfulie.caelum.com.br/ - Я настоятельно рекомендую обучающие / демонстрационные видеоролики, которые они размещают на vimeo:)
Я мог бы представить YMMV, но мне было очень легко начать разбираться в деталях REST после того, как я понял, что REST, по сути, был продолжением статических концепций WWW в области дизайна веб-приложений. Я написал (довольно длинный) пост о том же: Почему REST?
Content-Type: text / x-flamebait
В последнее время я задавал тот же вопрос, и я предполагаю, что половина проблемы с объяснением, почему полноценный REST - это хорошо, когда определение интерфейса для машинно-потребляемых данных - вот что время еще нет. Хорошо, вам понадобится действительно веская причина, чтобы игнорировать биты здравого смысла (URL-адреса определяют ресурсы, HTTP-команды определяют действия, и т. д. и т. д.) - Я ни в коем случае не предлагаю нам вернуться к мерзости, которая был SOAP. Но делать HATEOAS способом, одобренным Филдингом. (без нестандартных типов носителей) и удобство для машин, кажется, предлагает убывающая отдача: все очень хорошо, если использовать стандартный тип носителя для описывать допустимые переходы (если такой тип носителя существует), но где приложение вообще сложно агент вашего потребителя все еще необходимо знать, какие переходы нужно сделать для достижения желаемая цель (покупка билета или что-то еще), а она не может этого сделать если только ваш потребитель (человек) не скажет об этом.И если от него требуется встроить в свою программу внеполосное знание того, что путь с linkrels create_order => add_line => add_payment_info => Подтвердить правильный, а reset_order - неправильный путь, тогда я не видите, что гораздо более тяжкий грех заставлять его учить его XML парсер, что делать с application / x-vnd.yourname.order.
Я имею в виду, очевидно да меньше работы, если есть подходящий стандартный формат с библиотеками и еще много чего, что можно использовать повторно, но в (возможно, более распространенный) случай, которого нет, ваши варианты согласно Fielding-REST: (а) создать стандарт или (б) дополнить клиента, загрузив в него код. Если ты просто стремясь выполнить свою работу, а не изменить мир, вариант (c) "просто придумай что-нибудь", вероятно, выглядит довольно заманчиво, и я бы, например, не стал винить тебя в том, что ты это взял.
Эта статья хорошо классифицирует различия в нескольких стилях HTTP-приложений от чистоты WS-* до RESTian. Что мне нравится в этом посте, так это то, что он напоминает вам, что большая часть того, что мы называем REST, на самом деле лишь частично соответствует первоначальному определению Роя Филдинга.
В InfoQ есть целый раздел, посвященный большему количеству аспектов «что такое REST».
С точки зрения REST и SOAP, на этот вопрос, кажется, есть ряд хороших ответов, особенно выбранный ответ.