Arsitektur API internal dan eksternal

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?

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.

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.

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)

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.

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?