Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pola perutean API
Dalam lingkungan pengembangan yang gesit, tim otonom (misalnya regu dan suku) memiliki satu atau lebih layanan yang mencakup banyak layanan mikro. Tim mengekspos layanan ini APIs untuk memungkinkan konsumen mereka berinteraksi dengan kelompok layanan dan tindakan mereka.
Ada tiga metode utama untuk mengekspos HTTP APIs ke konsumen hulu dengan menggunakan nama host dan jalur:
|
|
| **Metode** | **Deskripsi** | **Contoh** |
| --- |--- |--- |
| [**Perutean nama host**](api-routing-hostname.md) | Paparkan setiap layanan sebagai nama host. | `billing.api.example.com` |
| [**Perutean jalur**](api-routing-path.md) | Paparkan setiap layanan sebagai jalur. | `api.example.com/billing` |
| [**Perutean berbasis header**](api-routing-http.md) | Paparkan setiap layanan sebagai header HTTP. | `x-example-action: something` |
Bagian ini menguraikan kasus penggunaan umum untuk ketiga metode perutean ini dan trade-offnya untuk membantu Anda memutuskan metode mana yang paling sesuai dengan kebutuhan dan struktur organisasi Anda.
# Pola perutean nama host
Routing dengan nama host adalah mekanisme untuk mengisolasi layanan API dengan memberikan masing-masing API nama hostnya sendiri; misalnya, atau. `service-a.api.example.com` `service-a.example.com`
## Kasus penggunaan khas
Perutean dengan menggunakan nama host mengurangi jumlah gesekan dalam rilis, karena tidak ada yang dibagi antara tim layanan. Tim bertanggung jawab untuk mengelola segala sesuatu mulai dari entri DNS hingga operasi layanan dalam produksi.
![\[Pola perutean nama host untuk mengekspos HTTP APIs ke konsumen hulu.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/cloud-design-patterns/images/routing-1.png)
## Pro
Perutean nama host sejauh ini merupakan metode yang paling mudah dan terukur untuk perutean HTTP API. Anda dapat menggunakan AWS layanan apa pun yang relevan untuk membangun arsitektur yang mengikuti metode ini―Anda dapat membuat arsitektur dengan [Amazon API Gateway [AWS AppSync](https://aws.amazon.com/appsync/), [Application Load Balancers](https://aws.amazon.com/elasticloadbalancing/) dan Amazon](https://aws.amazon.com/api-gateway/) Elastic [Compute Cloud ( EC2Amazon](https://aws.amazon.com/ec2/)), atau layanan lain yang sesuai dengan HTTP.
Tim dapat menggunakan perutean nama host untuk sepenuhnya memiliki subdomain mereka. Ini juga membuatnya lebih mudah untuk mengisolasi, menguji, dan mengatur penerapan untuk spesifik Wilayah AWS atau versi; misalnya, atau. `region.service-a.api.example.com` `dev.region.service-a.api.example.com`
## Kontra
Saat Anda menggunakan perutean nama host, konsumen Anda harus mengingat nama host yang berbeda untuk berinteraksi dengan setiap API yang Anda paparkan. Anda dapat mengurangi masalah ini dengan menyediakan SDK klien. Namun, klien SDKs datang dengan serangkaian tantangan mereka sendiri. Misalnya, mereka harus mendukung pembaruan bergulir, beberapa bahasa, pembuatan versi, mengkomunikasikan perubahan yang melanggar yang disebabkan oleh masalah keamanan atau perbaikan bug, dokumentasi, dan sebagainya.
Saat Anda menggunakan perutean nama host, Anda juga perlu mendaftarkan subdomain atau domain setiap kali Anda membuat layanan baru.
# Pola perutean jalur
Perutean berdasarkan jalur adalah mekanisme pengelompokan beberapa atau semua APIs di bawah nama host yang sama, dan menggunakan URI permintaan untuk mengisolasi layanan; misalnya, atau. `api.example.com/service-a` `api.example.com/service-b`
## Kasus penggunaan khas
Sebagian besar tim memilih metode ini karena mereka menginginkan arsitektur sederhana ― pengembang harus mengingat hanya satu URL seperti `api.example.com` untuk berinteraksi dengan HTTP API. Dokumentasi API seringkali lebih mudah dicerna karena sering disimpan bersama alih-alih dibagi di berbagai portal atau. PDFs
Routing berbasis jalur dianggap sebagai mekanisme sederhana untuk berbagi API HTTP. Namun, ini melibatkan overhead operasional seperti konfigurasi, otorisasi, integrasi, dan latensi tambahan karena beberapa hop. Ini juga membutuhkan proses manajemen perubahan yang matang untuk memastikan bahwa kesalahan konfigurasi tidak mengganggu semua layanan.
Pada AWS, ada beberapa cara untuk berbagi API dan rute secara efektif ke layanan yang benar. Bagian berikut membahas tiga pendekatan: HTTP service reverse proxy, API Gateway, dan Amazon CloudFront. Tak satu pun dari pendekatan yang disarankan untuk menyatukan layanan API bergantung pada layanan hilir yang berjalan. AWS Layanan dapat berjalan di mana saja tanpa masalah atau pada teknologi apa pun, selama mereka kompatibel dengan HTTP.
## Proxy terbalik layanan HTTP
Anda dapat menggunakan server HTTP seperti [NGINX](https://www.f5.com/go/product/welcome-to-nginx) untuk membuat konfigurasi routing dinamis. Dalam arsitektur [Kubernetes](https://kubernetes.io/), Anda juga dapat membuat aturan ingress untuk mencocokkan jalur ke layanan. (Panduan ini tidak mencakup masuknya Kubernetes; lihat dokumentasi [Kubernetes untuk informasi selengkapnya](https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource).)
Konfigurasi berikut untuk NGINX secara dinamis memetakan permintaan HTTP ke. `api.example.com/my-service/` `my-service.internal.api.example.com`
```
server {
listen 80;
location (^/[\w-]+)/(.*) {
proxy_pass $scheme://$1.internal.api.example.com/$2;
}
}
```
Diagram berikut menggambarkan layanan HTTP metode reverse proxy.
![\[Menggunakan proxy terbalik layanan HTTP untuk perutean jalur.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/cloud-design-patterns/images/routing-2.png)
Pendekatan ini mungkin cukup untuk beberapa kasus penggunaan yang tidak menggunakan konfigurasi tambahan untuk mulai memproses permintaan, memungkinkan API hilir mengumpulkan metrik dan log.
Untuk bersiap-siap menghadapi kesiapan produksi operasional, Anda akan ingin dapat menambahkan observabilitas ke setiap tingkat tumpukan Anda, menambahkan konfigurasi tambahan, atau menambahkan skrip untuk menyesuaikan titik masuk API Anda untuk memungkinkan fitur yang lebih canggih seperti pembatasan tarif atau token penggunaan.
### Pro
Tujuan utama dari metode proxy reverse layanan HTTP adalah untuk menciptakan pendekatan yang dapat diskalakan dan dikelola untuk menyatukan APIs ke dalam satu domain sehingga tampak koheren untuk setiap konsumen API. Pendekatan ini juga memungkinkan tim layanan Anda untuk menerapkan dan mengelola sendiri APIs, dengan overhead minimal setelah penerapan. AWS layanan terkelola untuk penelusuran, seperti [AWS X-Ray](https://aws.amazon.com/xray/)atau [AWS WAF](https://aws.amazon.com/waf/), masih berlaku di sini.
### Kontra
Kelemahan utama dari pendekatan ini adalah pengujian ekstensif dan manajemen komponen infrastruktur yang diperlukan, meskipun ini mungkin tidak menjadi masalah jika Anda memiliki tim rekayasa keandalan situs (SRE) di tempat.
Ada titik kritis biaya dengan metode ini. Pada volume rendah hingga menengah, ini lebih mahal daripada beberapa metode lain yang dibahas dalam panduan ini. Pada volume tinggi, ini sangat hemat biaya (sekitar 100 ribu transaksi per detik atau lebih baik).
## API Gateway
Layanan [Amazon API Gateway](https://aws.amazon.com/api-gateway/) (REST APIs dan HTTP APIs) dapat merutekan lalu lintas dengan cara yang mirip dengan metode proxy terbalik layanan HTTP. Menggunakan gateway API dalam mode proxy HTTP menyediakan cara sederhana untuk membungkus banyak layanan ke titik masuk ke subdomain tingkat atas`api.example.com`, dan kemudian permintaan proxy ke layanan bersarang; misalnya,. `billing.internal.api.example.com`
Anda mungkin tidak ingin terlalu terperinci dengan memetakan setiap jalur di setiap layanan di gateway API root atau inti. Sebagai gantinya, pilih jalur wildcard seperti meneruskan permintaan `/billing/*` ke layanan penagihan. Dengan tidak memetakan setiap jalur di gateway API root atau inti, Anda mendapatkan lebih banyak fleksibilitas atas jalur Anda APIs, karena Anda tidak perlu memperbarui gateway API root dengan setiap perubahan API.
![\[Perutean jalur melalui API Gateway.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/cloud-design-patterns/images/routing-3.png)
### Pro
Untuk mengontrol alur kerja yang lebih kompleks, seperti mengubah atribut permintaan, REST APIs mengekspos Apache Velocity Template Language (VTL) untuk memungkinkan Anda memodifikasi permintaan dan respons. REST APIs dapat memberikan manfaat tambahan seperti ini:
+ [Auth N/Z dengan AWS Identity and Access Management (IAM), [Amazon Cognito](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/cognito.html),](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/authentication.html) [atau otorisasi AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)
+ [AWS X-Ray untuk melacak](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-understanding-xray-traces.html)
+ [Integrasi dengan AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)
+ [Pembatasan tarif dasar](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ Token penggunaan untuk mendorong konsumen ke berbagai tingkatan (lihat [permintaan Throttle API untuk throughput yang lebih baik dalam dokumentasi API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) Gateway)
### Kontra
Pada volume tinggi, biaya mungkin menjadi masalah bagi beberapa pengguna.
## CloudFront
Anda dapat menggunakan [fitur pemilihan asal dinamis](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html) di [Amazon CloudFront](https://aws.amazon.com/cloudfront/) untuk memilih asal (layanan) secara kondisional untuk meneruskan permintaan. Anda dapat menggunakan fitur ini untuk merutekan sejumlah layanan melalui satu nama host seperti`api.example.com`.
### Kasus penggunaan khas
Logika perutean hidup sebagai kode dalam fungsi Lambda @Edge, sehingga mendukung mekanisme perutean yang sangat dapat disesuaikan A/B seperti pengujian, rilis kenari, penandaan fitur, dan penulisan ulang jalur. Ini diilustrasikan dalam diagram berikut.
![\[Jalur routing melalui CloudFront.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/cloud-design-patterns/images/routing-4.png)
### Pro
Jika Anda memerlukan respons API caching, metode ini adalah cara yang baik untuk menyatukan kumpulan layanan di balik satu titik akhir. Ini adalah metode hemat biaya untuk menyatukan koleksi. APIs
Juga, CloudFront mendukung [enkripsi tingkat lapangan](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html) serta integrasi dengan AWS WAF untuk pembatasan tarif dasar dan dasar. ACLs
### Kontra
Metode ini mendukung maksimal 250 asal (layanan) yang dapat disatukan. Batas ini cukup untuk sebagian besar penerapan, tetapi dapat menyebabkan masalah dengan sejumlah besar APIs saat Anda mengembangkan portofolio layanan Anda.
Memperbarui fungsi Lambda @Edge saat ini membutuhkan waktu beberapa menit. CloudFront juga membutuhkan waktu hingga 30 menit untuk menyelesaikan penyebaran perubahan ke semua titik kehadiran. Ini pada akhirnya memblokir pembaruan lebih lanjut sampai selesai.
# Pola perutean header HTTP
Routing berbasis header memungkinkan Anda untuk menargetkan layanan yang benar untuk setiap permintaan dengan menentukan header HTTP dalam permintaan HTTP. Misalnya, mengirim header `x-service-a-action: get-thing` akan memungkinkan Anda untuk `get thing` dari`Service A`. Jalur permintaan masih penting, karena menawarkan panduan tentang sumber daya mana yang Anda coba kerjakan.
Selain menggunakan perutean header HTTP untuk tindakan, Anda dapat menggunakannya sebagai mekanisme untuk perutean versi, mengaktifkan flag fitur, A/B pengujian, atau kebutuhan serupa. Pada kenyataannya, Anda mungkin akan menggunakan perutean header dengan salah satu metode perutean lainnya untuk membuat yang kuat. APIs
Arsitektur untuk perutean header HTTP biasanya memiliki lapisan perutean tipis di depan layanan mikro yang merutekan ke layanan yang benar dan mengembalikan respons, seperti yang diilustrasikan dalam diagram berikut. Lapisan routing ini dapat mencakup semua layanan atau hanya beberapa layanan untuk mengaktifkan operasi seperti perutean berbasis versi.
![\[Perutean header HTTP.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/cloud-design-patterns/images/routing-5.png)
## Pro
Perubahan konfigurasi memerlukan sedikit usaha dan dapat diotomatisasi dengan mudah. Metode ini juga fleksibel dan mendukung cara-cara kreatif untuk mengekspos hanya operasi tertentu yang Anda inginkan dari layanan.
## Kontra
Seperti halnya metode routing hostname, HTTP header routing mengasumsikan bahwa Anda memiliki kontrol penuh atas klien dan dapat memanipulasi header HTTP kustom. Proxy, jaringan pengiriman konten (CDNs), dan penyeimbang beban dapat membatasi ukuran header. Meskipun ini tidak mungkin menjadi masalah, ini bisa menjadi masalah tergantung pada berapa banyak header dan cookie yang Anda tambahkan.