Arsitektur API internal dan eksternal

19

Perusahaan tempat saya bekerja mempertahankan produk SaaS yang sukses yang tumbuh "organik" selama bertahun-tahun. Kami berencana untuk memperluas jajaran produk baru yang akan berbagi data dengan produk yang sudah ada. Untuk mendukung ini, kami mencari cara untuk menggabungkan logika bisnis menjadi satu tempat: lapisan layanan web. Lapisan WS akan digunakan oleh:

  • Aplikasi web
  • Alat untuk mengimpor data
  • Alat untuk berintegrasi dengan perangkat lunak klien lain (bukan API per se)

Kami juga ingin membuat API yang dapat digunakan oleh pelanggan kami yang mampu menggunakannya untuk membuat integrasi mereka sendiri. Kami bergumul dengan pertanyaan berikut:

Haruskah API internal (alias lapisan WS) dan API eksternal menjadi satu di yang sama, dengan pengaturan keamanan dan izin untuk mengontrol apa yang dapat dilakukan oleh siapa, atau mereka harus menjadi dua aplikasi terpisah di mana API eksternal hanya memanggil API internal seperti aplikasi lainnya? Sejauh ini dalam perdebatan kami tampaknya memisahkan mereka mungkin lebih aman, tetapi akan menambah biaya tambahan.

Apa yang telah dilakukan orang lain dalam situasi yang sama?

Drew Goodwin
sumber
Jika Anda membeli kerangka kerja yang bagus untuk SOA, semua perdebatan ini bisa diperdebatkan. Apakah Anda berencana untuk meluncurkan kerangka kerja SOA Anda sendiri? Mengapa? Jika ini adalah produk yang sukses, mengapa tidak melisensikan JCAPS dari Oracle? Atau WebSphere dari IBM? Kemudian keamanan lapisan WS menjadi di mana-mana dan transparan.
S.Lott
1
@ S.Lott Benar-benar tidak sulit untuk menulis lapisan SOA. Tidak satu pun dari platform tersebut yang berbasis REST; ini tahun 2012 bukan? Kedengarannya 'keras'.
Evan Plaice
Mengapa tidak memiliki lapisan layanan di bagian atas model domain Anda, maka Anda dapat menggunakan layanan yang sama secara internal dengan kode sumber Anda.
M.abuelezz

Jawaban:

13

Itu selalu baik untuk makan makanan anjing Anda sendiri. Satu API juga harus lebih mudah dikelola daripada dua, bahkan jika Anda memasukkan beberapa overhead untuk otentikasi dan otorisasi.

Aneurisma9
sumber
4
Saya suka cara Anda mengatakannya. Memiliki dua lapisan yang terpisah pada akhirnya akan berarti mengubah hal-hal di dua tempat banyak kali di masa depan, pengujian tambahan, dan banyak kegilaan umum mencoba mencari tahu mengapa hal-hal menjadi tidak sinkron. Jika saya memiliki reputasi yang cukup untuk memilih jawaban Anda, saya akan :)
Drew Goodwin
5

Meskipun saya setuju dengan Aneurysm9 kadang-kadang Anda tidak ingin mengekspos semua kemampuan sistem Anda. Dalam hal ini memiliki dua API akan lebih disukai ... TETAPI jika Anda melakukannya memilih cara ini ... pastikan bahwa semua fungsi umum berbagi API yang sama, yaitu bahwa satu menjadi versi diperpanjang dari yang lain sebagai lawan dua berbeda set kode.

Dengan cara ini Anda bisa menggunakan milik Anda sendiri sementara memiliki tempat untuk pekerjaan pribadi, sensitif, eksperimental untuk maju sambil tetap memungkinkan Anda untuk menerbitkan dan menggunakan hal-hal baru tanpa terlalu banyak mengubah API publik.

Newtopian
sumber
3
Saya pikir kita sepakat di sini. Gunakan lapisan keamanan untuk membatasi superset fungsionalitas untuk pengguna internal. Dengan begitu, Anda memiliki satu API tetapi beberapa tingkat izin untuk mengakses API.
Aneurysm9
Saya sedang berpikir untuk melakukan ini sendiri dan menanganinya dengan menjadikan aplikasi saya pengguna sendiri dengan hak istimewa yang lebih tinggi. Sulit untuk membungkus otak saya. Saya rasa saya perlu menerapkan Hammock Driven Development yang satu ini.
AJB
4

Saya pernah mengalami ini sebelumnya (berkali-kali) dan yang akhirnya saya sukai adalah:

Keluarkan BL dari situs web. Jadikan situs web sebagai konsumen API. Perlakukan situs web hanya sebagai beberapa klien lain dari API Anda. API Anda ADALAH layanan.

Jika Anda mendapati diri Anda berpikir bahwa Anda memerlukan metode API khusus hanya untuk situs web, pikirkan lagi! Jika itu baik untuk angsa, itu bagus untuk memandang sebentar. Jika Anda benar-benar benar-benar membutuhkan fungsionalitas khusus untuk situs web, saya akan menyarankan bahwa apa yang benar-benar Anda temukan adalah perbedaan dalam "profil pengguna" dan oleh karena itu ini adalah situasi di mana API masih harus mendukung fungsi "khusus", tetapi kemudian Anda kendalikan melalui otorisasi.

Tidak meyakinkan?

Ambil paradigma ini selangkah lebih maju ...

Aplikasi telepon berjalan pada platform di mana bytecode dijalankan, aplikasi tinggal di telepon dan mengkonsumsi layanan API melalui HTTP / JSON

Situs web adalah aplikasi yang berjalan pada platform di mana HTML + Javascript dijalankan, aplikasi tinggal di browser dan menggunakan layanan API melalui HTTP / JSON

Sama sama!

Perluas itu ke tablet, TV, platform ponsel lain, plugin, aplikasi pihak ketiga, mashup, ...

Banyak pengalaman pengguna yang berbeda semuanya terhubung ke API umum.

Aplikasi Anda ADALAH API. Situs web ini hanya satu klien (banyak)

Jason Glover
sumber
Memahami bahwa API adalah seluruh lapisan aplikasi, dan berbagai versi (OS, browser, tablet, telepon) hanyalah klien dari API yang membuat saya ke A-Ha! saat sekarang.
AJB
2

Gunakan satu API

Jika Anda menerapkan API layanan sebagai lapisan REST, cukup tambahkan otentikasi ke rute yang dilindungi.

Anda mungkin ingin menggunakan kerangka pengembangan yang tidak terlalu banyak menghasilkan 'sihir'. Sesuatu di mana Anda dapat menentukan rute secara langsung tanpa banyak rekayasa terbalik.

Pikirkan sesuatu seperti Node.js / Express, python / pylons, python / google app engine, dll.

Saya baru-baru ini menerapkan ini di Google App Engine untuk REST / Datastore API dan saya tidak berpikir itu bisa lebih mudah. Pengontrol diimplementasikan sebagai kelas dan permintaan HTTP berikutnya (yaitu GET / POST / PUT / DELETE) diimplementasikan sebagai metode dari kelas-kelas tersebut. Saya berhasil menerapkan basic-auth sebagai dekorator. Itu membuat menambahkan persyaratan otentikasi ke permintaan sesederhana melampirkan dekorator @basicAuth.

Dengan begitu, saya bisa membuat permintaan GET yang masuk untuk publik menambahkan persyaratan auth ke permintaan POST / PUT / DELETE pada controller yang sama untuk model itu.

Jika Anda tahu cara berbicara di REST, hidup menjadi jauh lebih mudah karena dukungan REST sudah secara inheren dimasukkan ke server web yang pernah ada (yaitu HTTP hanyalah jenis REST API). Anda bahkan dapat memilih untuk kompresi gzip transparan jika Anda mengirim banyak data.

Evan Plaice
sumber
-1

Kesan pertama saya adalah bahwa itu harus API yang sama, dan bahwa keamanan Anda harus berada pada lapisan yang berbeda sama sekali. Mungkin ditangani oleh front web?

vegai
sumber
2
terkadang masalah keamanan akan menggali lebih dalam daripada sekadar enkripsi dan tanda tangan transaksi. Dengan demikian sangat mungkin bahwa beberapa, atau bahkan banyak, elemen berorientasi keamanan merayap di API utama Anda. Ini berkata, saya akan setuju dengan Anda dalam mencoba untuk menyimpannya terpisah mungkin.
Newtopian