Плюси і мінуси розважальної архітектури [закрито]

Найпоширеніша дискусія, яку я бачив щодо плюсів і мінусів REST, як правило, відповідає цій дискусії стосовно SOAP. У мене немає жодного досвіду. В даний час я стикаюся з рішенням, яке мій брак досвіду важко оцінює. Я починаю розробляти додаток, який містить декілька компонентів - насамперед адміністративний аспект, який дозволяє власникові адмініструвати декілька сайтів - і публічний інтерфейс користувача, який дозволяє користувачеві взаємодіяти з даними, що зберігаються на хості. Мені потрібно оцінити наслідки того, щоб дозволити розміщення останньої частини де завгодно і спілкуватися з першою за допомогою архітектури RESTful - або вимагати, щоб обидва компоненти перебували на одному хості. Які ключові наслідки розвитку архітектури RESTful, особливо щодо її потенціалу в наступних областях:

1: Безпека 2: Продуктивність 3: Складність інтерфейсу

EDIT: Дивлячись на деякі відповіді на це питання - я повинен уточнити. Я не шукаю порівняння з 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 включають процесори, до яких можна підключити, щоб забезпечити певний вигляд безпеки, але ви все одно відповідаєте за пошук їх та встановлення їх на місце.

1. Безпека: Використовуйте HTTPS. Це стосується обох.
2. Продуктивність: . REST дешевший для процесора (менше аналізує, марширує, розкручує). Також кешування з REST - це шматок пирога.
3. Складність: REST вимагає набагато менше щодо налаштування, це просто GET / POST зрештою. SOAP вимагає набагато більше адміністрування для підтримки (wsdl тощо), але трохи простіше, якщо ваш IDE підтримує його.

Я думаю, що SOAP занадто роздутий, коли ви можете зробити те ж саме з REST та деяким вмістом / mime-типами. Крім того, SOAP приносить великі накладні витрати, завдяки природі обгортання та тому, що він є загальнішим і не обмежується HTTP. SOAP спокусливо використовувати, якщо ваш IDE підтримує його належним чином, і ви не хочете вивчати HTTP. Але для мене REST набагато простіший у використанні та набагато більш зручний для Інтернету.

На сьогоднішній день є дуже хороші API REST для використання. Якщо ви перебуваєте на Java, то Jax-RS дійсно крутий. Для деяких людей це схоже на порно.

Я думаю, що найбільша перевага REST - це відірватися від архітектури RPC. REST викриває ресурси, а не процеси. Це дозволяє створити слабко пов'язану систему, де зміни, вдосконалення, навіть відмови однієї частини мають обмежений (негативний) вплив на інші частини.

На жаль, поширене неправильне використання REST - це викриття вашої внутрішньої структури даних (у гірших випадках - це CRUD вашої бази даних, так-так). Це дуже важко зробити це безпечно. Правильне використання полягає в тому, щоб викрити об'єкти високого рівня, що відповідають частині тієї системи, якою ви керуєте, і вільно повернути коди статусу помилок на будь-яку невідповідність.

Ще одна часто недооцінена частина REST - ідентифікація більшості дієслів. Не тільки GET, але і PUT і DELETE повинні бути абсолютно однаковим результатом, якщо застосовувати їх один раз або кілька разів (ви не можете повернути 404, якщо вже видалено, або "no change", якщо клієнт PUTting той же). Це призводить до надійних систем та меншої взаємозалежності точних інтерпретацій семантики.

Стандарти WS- * здебільшого стосуються роботи RPC через SOAP / HTTP. Отже, все мислення, яке перейшло до CORBA та J2EE та їхніх попередників, здебільшого перейшло до того ж, що робиться в XML. Це означає такі речі, як декларації про типи та контракти на обслуговування, обмін метаданими, декларативна безпека тощо. Все те, що є справжнім "підприємством". Його надмірно використовували навіть на підприємстві, відверто кажучи.

Людям, які будують Інтернет-додаток, такий як ви, майже напевно було б краще використовувати архітектуру RESTful. Практично будь-яка платформа може споживати її і робити це просто та, не переживаючи, яку версію, яку специфікацію ви використовуєте, і безліч натурщиків щодо конверсії для певного типу тощо.

Єдиною великою перевагою SOAP перед поточними реалізаціями REST є те, що SOAP легше подолати - більшість RESTful клієнтів вимагають від мене розуміння інтерфейсу та запису клієнта якогось типу. Для SOAP я просто вказую на нього wsdl.exe, і він генерує для мене класи.