Самая распространенная дискуссия о плюсах и минусах REST, которую я видел, имеет тенденцию формировать эту дискуссию относительно SOAP. У меня нет опыта ни в одном. В настоящее время я сталкиваюсь с решением, которое мне сложно оценить из-за недостатка опыта. Я начинаю разрабатывать приложение, которое имеет несколько компонентов - в первую очередь административный аспект, который позволяет владельцу администрировать несколько сайтов - и общедоступный пользовательский интерфейс, который позволяет пользователю взаимодействовать с данными, хранящимися на хосте. Мне нужно оценить последствия того, что последняя часть может быть размещена где угодно и взаимодействовать с первой через архитектуру RESTful - или требовать, чтобы оба компонента находились на одном хосте. Каковы основные последствия разработки архитектуры RESTful, особенно в отношении ее возможностей в следующих областях:
1: безопасность 2: производительность 3: сложность интерфейса
РЕДАКТИРОВАТЬ: Глядя на некоторые ответы на этот вопрос - я должен уточнить. Я не ищу сравнение с SOAP - скорее обзор приложений REST и приложений, где все компоненты находятся на одном хосте. (спасибо за эти ответы, хотя!)
источник
Ответы:
Учитывая эти области, я могу дать приблизительный обзор, но я не могу сделать ваши выводы для вас. Существуют две основные области, в которых два протокола различаются:
Формат сообщения проще всего понять. Пакет SOAP для запросов и ответов довольно тяжелый. Есть конверт SOAP, который содержит заголовок и раздел тела. Заголовок может использоваться несколькими фильтрами в цепочке запросов для выполнения какой-либо идентификации, авторизации и т. Д. Однако анализ XML является дорогостоящим, что приводит к определенным потерям в масштабируемости вашей системы. Как много зависит от уровня обработки SOAP в вашем стеке.
Обнаружение службы - то, где вы, вероятно, будете иметь наибольшее количество разногласий REST по своей природе обеспечивает предсказуемые конечные точки, а содержимое запроса представляет собой простой HTTP-запрос. Преимущество заключается в том, что нет никаких дополнительных затрат, и конечные пользователи могут в значительной степени догадаться, как сделать то, что им нужно, как только они поймут структуру URL вашего сайта. Конечно, наивные люди, которые заботятся о безопасности, увидят в этом слабость. В конце концов, с SOAP вы должны использовать WSDL, чтобы знать, каковы конечные точки. Конечно, с SOAP вы получили полный формат сообщения, чтобы вы могли проводить более целенаправленные атаки.
В разбивке по категориям, которые вы дали:
Безопасность
Ни один из них не является более безопасным, чем другой. Используйте хорошие принципы безопасности:
Помни о безвестности! = Безопасность.
Производительность
Исходная производительность и масштабируемость перейдут в REST из-за запроса, следующего за простыми протоколами HTTP. Большинство стеков SOAP используют синтаксический анализ SAX (анализ на основе событий), что значительно улучшает масштабируемость стеков SOAP, но оказывает ощутимое влияние на издержки. SOAP имеет обычные накладные расходы на обработку HTTP в дополнение к накладным расходам на синтаксический анализ XML. У REST просто накладные расходы на обработку HTTP.
сложность
С точки зрения системы, REST побеждает. Меньше движущихся частей, более узкая цепочка запросов и т. Д. Это означает, что сделать надежнее проще.
С точки зрения программиста, SOAP может победить, если IDE или среда, которую вы используете, обеспечивают хорошую поддержку. По сути, с REST вы обязаны выполнять работу по предварительной обработке (аутентификация / авторизация / и т. Д.), В то время как с помощью SOAP большая часть этого может быть выполнена с помощью подключаемой цепочки обработки.
Мои предпочтения
Мне очень удобно работать с HTTP-запросами, и я знаю, как работает веб. В результате подход REST для меня более предпочтителен. Однако я знаю, что некоторым из моих клиентов это неудобно. Они прочитали какую-то отраслевую статью, осуждающую безопасность REST по сравнению с SOAP и т. Д. Суть в том, что ни один из подходов не гарантирует безопасность. Вы должны убедиться, что приложение является настолько безопасным, насколько это необходимо. Очевидно, что социальное веб-приложение не требует (или не желает) такой безопасности, как банковская или государственная система. Многие стеки SOAP включают в себя процессоры, которые вы можете подключить для обеспечения некоторого подобия безопасности, но вы все равно несете ответственность за их поиск и установку.
источник
Я думаю, что мыло слишком раздут, когда вы можете сделать то же самое с REST и некоторыми типами содержимого / mime. Кроме того, SOAP приносит много накладных расходов из-за своей природы обертывания оберток и того факта, что он носит более общий характер и не ограничивается HTTP. SOAP заманчиво использовать, если ваша IDE поддерживает его должным образом и вы не хотите изучать HTTP. Но для меня REST намного проще в использовании и гораздо более дружественен к вебу.
В настоящее время есть очень хорошие API REST для использования. Если вы в Java, то Jax-RS действительно крутой. Для некоторых людей, это походит на порно.
источник
Я думаю, что самое большое преимущество REST - это отказ от архитектуры RPC. REST предоставляет ресурсы, а не процессы. Это позволяет вам создать слабо связанную систему, в которой изменения, улучшения, даже сбои одной части имеют ограниченное (негативное) влияние на другие части.
К сожалению, распространенным неправильным использованием REST является раскрытие ваших внутренних структур данных (в худшем случае это CRUD вашей базы данных, тьфу). Это делает это очень трудно сделать это безопасно. «Правильное» использование состоит в том, чтобы выставлять высокоуровневые объекты, относящиеся к той части системы, с которой вы работаете, и свободно возвращать коды состояния ошибок при любых несоответствиях.
Другая часто пропускаемая часть REST - идемпотентность большинства глаголов. Не только GET, но также PUT и DELETE должны быть в точности одинаковыми, если их применять один или несколько раз (вы можете не возвращать 404, если он уже удален, или «без изменений», если клиент PUTting то же самое). Это приводит к надежным системам и меньшей взаимозависимости точных интерпретаций семантики.
источник
Стандарты WS- * в основном касаются запуска RPC через SOAP / HTTP. Таким образом, все размышления, связанные с CORBA, J2EE и их предшественниками, в основном перешли к тому же виду вещей в XML. Это означает такие вещи, как объявления типов и контракты на обслуживание, обмен метаданными, декларативная безопасность и т. Д. Все эти реальные "корпоративные" вещи. Честно говоря, его используют даже на предприятии.
Людям, создающим интернет-приложения, такие как вы, почти наверняка лучше использовать архитектуру RESTful. Практически любая платформа может использовать его и делать это просто и не беспокоясь о том, какую версию какой спецификации вы используете, а также о множестве специфических специфических особенностей инструмента для преобразования типов и т. Д.
источник
Единственное большое преимущество SOAP перед текущими реализациями REST состоит в том, что SOAP проще обрабатывать - большинству клиентов RESTful требуется, чтобы я понял интерфейс и написал своего рода клиента. Для SOAP я просто указываю на него wsdl.exe, и он генерирует классы для меня.
источник