Чи є поганий вибір споживати REST API з інтерфейсу?

Використання REST API для інтерфейсного коду є значною і досить поширеною практикою.
Тим не менш, мені було цікаво, якщо його використання також для заднього кінця може бути гарним вибором.

Що я маю на увазі, залишаючи тягар вилучення даних з бази даних все в API, а потім викликати його з інших частин мого back-end (в основному, перегляди і контролери), коли мені потрібно запитувати базу даних, а не робити це безпосередньо.

Мені дуже хвилюється, що обмін кодом між інтерфейсом та інтерфейсом , і використання API як звичайного джерела даних буде дуже зручним.

So the question is, are there some reasons which make this a bad idea?

4
Зазвичай це називається сервіс-орієнтована архітектура .
додано Автор Philipp, джерело

5 Відповіді

Виділення компонентів з бази даних/позбавлення від прямих підключень до бази даних є загальною схемою. Переміщення доступу до проміжного програмного забезпечення/компонента, який оперує базою даних, може допомогти поліпшити безпеку та модульність, а також забезпечити місце для здійснення перевірки та інтерпретації даних, які в іншому випадку "потраплять" до SQL, збережених процедур і коду бази даних на стороні клієнта. Проти цього ви повинні зважити розробку, час виконання і, можливо, економічну вартість цього інтерфейсу. Але на багатьох масштабах проектів, передні кінці даних часто вважаються хорошим вибором.

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

Деякі причини, з яких ви все ще можете використовувати RESTful бекенд: простота, узгодженість (кожен клієнт, локальний або віддалений, проходить лише через один API) і час виходу на ринок (наприклад, не потрібно вивчати інший стиль API/взаємодії). Вони припускають, що ви розкриваєте вашу базу даних відносно безпосередньо через RESTful API. Якщо це суворо для використання компонентів під вашим контролем, REST, ймовірно, не є найкращим вибором (для семантичного багатства або ефективності).

5
додано
Це велика відповідь. Якщо ви тримаєте контролери REST тонкими і відповідальними лише за "розбір запиту, виклик класу lib бізнес-моделі, результат повернення", то цілком доцільно викликати цю бібліотеку прямо. Тільки будьте обережні, не пов'язані з HTTP-логіки у ваші контролери.
додано Автор RubberDuck, джерело
Дякуємо за відповідь! І так, однією з головних проблем є неефективність, і я думаю про те, як абстрагувати рівень доступу з реалізації API, так що я можу отримати доступ до неї в REST-моді, але безпосередньо з коду, таким чином виключаючи всі накладні витрати через HTTP
додано Автор Henrik, джерело

Я думаю, що всеохоплююче обґрунтування виходу з доступу до даних RESTful API буде відношенням доступу до даних до решти середовища.

Подумайте про це, влада API, як правило, величезна кількість і різноманітність "клієнтських" виконавців, які можуть її споживати. Це не повинно відрізнятися у вашому випадку.

Іншими словами, якщо ви повинні мати декількох споживачів і різних викликаючих цього ж доступу до даних і/або шукати, щоб масштабувати це, то я думаю, що це має сенс.

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

3
додано

Не обов'язково. Проміжне програмне забезпечення не може обробити все. Є три приклади, які я завжди висвітлюю, щоб показати це: дозування, форварди та апі-ланцюжки. Всі ці переваги, перебуваючи в межах оригінального запиту, але в додатках, часто повинні залишати і повертатися через ворота проксі/api.

Шляхом абстрагування вводу-виводу з api і перенесення його на перехоплювач, ви можете використовувати prehandler/posthandler для передачі зв'язку і використання одного потоку для обробки циклу.

Потік введення-виведення від api-воріт до екземпляра прикладу до інструменту відповіді - це один константний потік і не порушений.

Дивіться абстракцію api та api chaining для отримання додаткової інформації/bobdobbes/api-abstraction-api-chaining )

0
додано
Це відкрите джерело наукових досліджень, які мене часто просять представити на SpringOne, Apple, Amazon, Mashery, Paypal та інших установах. Що я маю називати своєю приналежністю? Я:
додано Автор Ian Storm Taylor, джерело
Я розумію, що ви говорите повністю. Люди не сподіваються на самовдосконалення/євангелізацію. Але ви не можете одночасно скасувати його, не відміняючи наукового обговорення нових ідей. Ви повинні бути обережними в обох напрямках ... це хитра ситуація, яку я чую.
додано Автор Ian Storm Taylor, джерело
"Співтовариство має тенденцію голосувати за відверте самостійне просування і позначати його як спам. Розміщуйте відповідні відповіді, і якщо деякі (але не всі) стосуються вашого продукту або веб-сайту, це нормально. у ваших відповідях. ( Довідковий центр> Наша модель> Як не бути спамером )
додано Автор gnat, джерело
додано Автор gnat, джерело

Використання REST API з бекенда має дві переваги: ​​Вам не потрібно розробляти і документувати інший API, а у вас є лише один набір помилок, а не два.

Є два можливих заперечення: може бути, що ваш бекенд робить речі, які не вписуються в існуючий API (тому що він може дивитися на дані з протилежного напрямку, як це робить інтерфейс API). І можуть виникнути проблеми з продуктивністю: якщо бекенда використовує базу даних у десять разів більше, ніж робить інтерфейс, а це критично для продуктивності, то вам не потрібно найпростіший API, але найшвидший.

Тому перевірте, як ваш сервер буде використовувати базу даних і вирішувати звідти. Якщо ваш сервер відповідає функціональністю REST API і немає проблем із продуктивністю, використовуйте REST API.

0
додано
Навіть якщо backend є щасливий. Чи варто викривати весь доступ до db Falacies розподілених обчислень?
додано Автор glacier, джерело

A lot of good answers and comments. To me, it seems microservice oriented. The challenge is that there is slight overhead inserting a layer between your data access and the backend code that churns on that data. Overhead in terms of development time & cycles, and overhead in terms of code performance. But the upsides are that your application components are more loosely coupled so you can extend/change the code with less complexity. If everything that accesses the data does so through the API, then any changes you need to make to the underlying data model if you make the API handle seamlessly then you are done.

Навпаки, якщо декілька частин вашого коду отримують доступ до даних у декількох місцях, ви маєте більше розглянути та зробити і перевірити. Крім того, коли існує кілька місць, де бекенда код звертається до даних, існує тенденція до невідповідності.

0
додано