Mengakses data jarak jauh

Banyak solusi berbasis web modern memanfaatkan layanan web, yang dihosting oleh server web, untuk menyediakan fungsionalitas untuk aplikasi klien jarak jauh. Operasi yang diekspos layanan web merupakan API web.

Aplikasi klien harus dapat menggunakan API web tanpa mengetahui bagaimana data atau operasi yang diekspos API diterapkan. Ini mengharuskan API mematuhi standar umum yang memungkinkan aplikasi klien dan layanan web untuk menyetujui format data mana yang akan digunakan, dan struktur data yang dipertukarkan antara aplikasi klien dan layanan web.

Pengantar Transfer Status Representasional

Representational State Transfer (REST) adalah gaya arsitektur untuk membangun sistem terdistribusi berdasarkan hypermedia. Keuntungan utama dari model REST adalah didasarkan pada standar terbuka dan tidak mengikat implementasi model atau aplikasi klien yang mengaksesnya ke implementasi tertentu. Oleh karena itu, layanan web REST dapat diimplementasikan menggunakan Microsoft ASP.NET Core, dan aplikasi klien dapat dikembangkan menggunakan bahasa dan toolset apa pun yang dapat menghasilkan permintaan HTTP dan mengurai respons HTTP.

Model REST menggunakan skema navigasi untuk mewakili objek dan layanan melalui jaringan, yang disebut sebagai sumber daya. Sistem yang menerapkan REST biasanya menggunakan protokol HTTP untuk mengirimkan permintaan untuk mengakses sumber daya ini. Dalam sistem tersebut, aplikasi klien mengirimkan permintaan dalam bentuk URI yang mengidentifikasi sumber daya, dan metode HTTP (seperti GET, POST, PUT, atau DELETE) yang menunjukkan operasi yang akan dilakukan pada sumber daya tersebut. Isi permintaan HTTP berisi data apa pun yang diperlukan untuk melakukan operasi.

Respons dari permintaan REST menggunakan kode status HTTP standar. Misalnya, permintaan yang mengembalikan data yang valid harus menyertakan kode respons HTTP 200 (OK), sementara permintaan yang gagal menemukan atau menghapus sumber daya tertentu harus mengembalikan respons yang menyertakan kode status HTTP 404 (Not Found).

API web RESTful mengekspos sekumpulan sumber daya yang terhubung, dan menyediakan operasi inti yang memungkinkan aplikasi memanipulasi sumber daya tersebut dan dengan mudah menavigasi di antara mereka. Untuk alasan ini, URI yang merupakan API web RESTful khas berorientasi pada data yang dieksposnya, dan menggunakan fasilitas yang disediakan oleh HTTP untuk beroperasi pada data ini.

Data yang disertakan oleh aplikasi klien dalam permintaan HTTP, dan pesan respons yang sesuai dari server web, dapat disajikan dalam berbagai format, yang dikenal sebagai jenis media. Saat aplikasi klien mengirim permintaan yang mengembalikan data dalam isi pesan, aplikasi tersebut dapat menentukan jenis media yang dapat ditanganinya di header Terima permintaan. Jika server web mendukung jenis media ini, server dapat membalas dengan respons yang menyertakan header Tipe Konten yang menentukan format data dalam isi pesan. Kemudian tanggung jawab aplikasi klien untuk mengurai pesan respons dan menginterpretasikan hasil dalam isi pesan dengan tepat.

Untuk informasi selengkapnya tentang REST, lihat Desain API dan implementasi API di Microsoft Docs.

Mengonsumsi API RESTful

Aplikasi multi-platform eShop menggunakan pola Model-View-ViewModel (MVVM), dan elemen model pola mewakili entitas domain yang digunakan dalam aplikasi. Kelas pengontrol dan repositori dalam aplikasi referensi eShop menerima dan mengembalikan banyak objek model ini. Oleh karena itu, mereka digunakan sebagai objek transfer data (DTO) yang menyimpan semua data yang diteruskan antara aplikasi dan layanan mikro dalam kontainer. Manfaat utama menggunakan DTO untuk meneruskan data ke dan menerima data dari layanan web adalah dengan mengirimkan lebih banyak data dalam satu panggilan jarak jauh, aplikasi dapat mengurangi jumlah panggilan jarak jauh yang perlu dilakukan.

Membuat permintaan web

Aplikasi multi-platform eShop menggunakan HttpClient kelas untuk membuat permintaan melalui HTTP, dengan JSON digunakan sebagai jenis media. Kelas ini menyediakan fungsionalitas untuk mengirim permintaan HTTP secara asinkron dan menerima respons HTTP dari sumber daya yang diidentifikasi URI. Kelas HttpResponseMessage mewakili pesan respons HTTP yang diterima dari REST API setelah permintaan HTTP dibuat. Ini berisi informasi tentang respons, termasuk kode status, header, dan isi apa pun. Kelas HttpContent mewakili isi HTTP dan header konten, seperti Tipe Konten dan Pengodean Konten. Konten dapat dibaca menggunakan salah ReadAs satu metode, seperti ReadAsStringAsync dan ReadAsByteArrayAsync, tergantung pada format data.

Membuat permintaan GET

Kelas CatalogService ini digunakan untuk mengelola proses pengambilan data dari layanan mikro katalog. RegisterViewModels Dalam metode di MauiProgram kelas , CatalogService kelas terdaftar sebagai pemetaan jenis terhadap ICatalogService jenis dengan kontainer injeksi dependensi. Kemudian, ketika instans CatalogViewModel kelas dibuat, konstruktornya menerima ICatalogService type, yang diselesaikan kontainer injeksi dependensi, mengembalikan instans CatalogService kelas. Untuk informasi selengkapnya tentang injeksi dependensi, lihat Injeksi Dependensi.

Gambar di bawah ini menunjukkan interaksi kelas yang membaca data katalog dari layanan mikro katalog untuk ditampilkan oleh CatalogView.

CatalogView Ketika dinavigasi, OnInitialize metode di kelas CatalogViewModel dipanggil. Metode ini mengambil data katalog dari layanan mikro katalog, seperti yang ditunjukkan dalam contoh kode berikut:

public override async Task InitializeAsync()
{
    Products = await _productsService.GetCatalogAsync();
} 

Metode ini memanggil metode CatalogService instans yang disuntikkan GetCatalogAsync ke dalam CatalogViewModel oleh kontainer injeksi dependensi. Contoh kode berikut menunjukkan GetCatalogAsync metode :

public async Task<ObservableCollection<CatalogItem>> GetCatalogAsync()
{
    UriBuilder builder = new UriBuilder(GlobalSetting.Instance.CatalogEndpoint);
    builder.Path = "api/v1/catalog/items";
    string uri = builder.ToString();

    CatalogRoot? catalog = await _requestProvider.GetAsync<CatalogRoot>(uri);

    return catalog?.Data;          
} 

Metode ini membangun URI yang mengidentifikasi sumber daya yang akan dikirimi permintaan, dan menggunakan RequestProvider kelas untuk memanggil metode HTTP GET pada sumber daya, sebelum mengembalikan hasilnya CatalogViewModelke . Kelas RequestProvider berisi fungsionalitas yang mengirimkan permintaan dalam bentuk URI yang mengidentifikasi sumber daya, metode HTTP yang menunjukkan operasi yang akan dilakukan pada sumber daya tersebut, dan isi yang berisi data apa pun yang diperlukan untuk melakukan operasi. Untuk informasi tentang bagaimana RequestProvider kelas disuntikkan ke CatalogService kelas, lihat Injeksi Dependensi.

Contoh kode berikut menunjukkan GetAsync metode di RequestProvider kelas :

public async Task<TResult> GetAsync<TResult>(string uri, string token = "")
{
    HttpClient httpClient = GetOrCreateHttpClient(token);
    HttpResponseMessage response = await httpClient.GetAsync(uri);

    await HandleResponse(response);
    TResult result = await response.Content.ReadFromJsonAsync<TResult>();

    return result;
}

Metode ini memanggil GetOrCreateHttpClient metode , yang mengembalikan instans HttpClient kelas dengan kumpulan header yang sesuai. Kemudian mengirimkan permintaan asinkron GET ke sumber daya yang diidentifikasi oleh URI, dengan respons disimpan dalam HttpResponseMessage instans. Metode HandleResponse ini kemudian dipanggil, yang melemparkan pengecualian jika respons tidak menyertakan kode status HTTP yang berhasil. Kemudian respons dibaca sebagai string, dikonversi dari JSON ke CatalogRoot objek, dan dikembalikan ke CatalogService.

Metode GetOrCreateHttpClient ini ditunjukkan dalam contoh kode berikut:

private readonly Lazy<HttpClient> _httpClient =
    new Lazy<HttpClient>(
        () =>
        {
            var httpClient = new HttpClient();
            httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
            return httpClient;
        },
        LazyThreadSafetyMode.ExecutionAndPublication);

private HttpClient GetOrCreateHttpClient(string token = "")
    {
        var httpClient = _httpClient.Value;

        if (!string.IsNullOrEmpty(token))
        {
            httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token);
        }
        else
        {
            httpClient.DefaultRequestHeaders.Authorization = null;
        }

        return httpClient;
    }

Metode ini menggunakan membuat instans baru atau mengambil instans HttpClient kelas yang di-cache, dan mengatur header Terima dari permintaan apa pun yang dibuat oleh HttpClient instans ke application/json, yang menunjukkan bahwa ia mengharapkan konten respons apa pun diformat menggunakan JSON. Kemudian, jika token akses diteruskan sebagai argumen ke GetOrCreateHttpClient metode , token tersebut ditambahkan ke Authorization header permintaan apa pun yang dibuat oleh HttpClient instans, diawali dengan string Bearer. Untuk informasi selengkapnya tentang otorisasi, lihat Otorisasi.

GetAsync Ketika metode di RequestProvider kelas memanggil HttpClient.GetAsync, Items metode di CatalogController kelas dalam Catalog.API proyek dipanggil, yang ditampilkan dalam contoh kode berikut:

[HttpGet]
[Route("[action]")]
public async Task<IActionResult> Items(
    [FromQuery]int pageSize = 10, [FromQuery]int pageIndex = 0)
{
    var totalItems = await _catalogContext.CatalogItems
        .LongCountAsync();

    var itemsOnPage = await _catalogContext.CatalogItems
        .OrderBy(c => c.Name)
        .Skip(pageSize * pageIndex)
        .Take(pageSize)
        .ToListAsync();

    itemsOnPage = ComposePicUri(itemsOnPage);
    var model = new PaginatedItemsViewModel<CatalogItem>(
        pageIndex, pageSize, totalItems, itemsOnPage);           

    return Ok(model);
}

Metode ini mengambil data katalog dari database SQL menggunakan EntityFramework, dan mengembalikannya sebagai pesan respons yang menyertakan kode status HTTP yang berhasil, dan kumpulan instans berformat CatalogItem JSON.

Membuat permintaan POST

Kelas BasketService ini digunakan untuk mengelola proses pengambilan dan pembaruan data dengan layanan mikro kerak. RegisterAppServices Dalam metode di MauiProgram kelas , BasketService kelas terdaftar sebagai pemetaan jenis terhadap IBasketService jenis dengan kontainer injeksi dependensi. Kemudian, ketika instans BasketViewModel kelas dibuat, konstruktornya menerima IBasketService jenis, yang diselesaikan kontainer injeksi dependensi, mengembalikan instans BasketService kelas. Untuk informasi selengkapnya tentang injeksi dependensi, lihat Injeksi Dependensi.

Gambar di bawah ini menunjukkan interaksi kelas yang mengirim data ke basket yang ditampilkan oleh BasketView, ke layanan mikro ke basket.

Ketika item ditambahkan ke kerajang belanja, ReCalculateTotalAsync metode di kelas dipanggil BasketViewModel . Metode ini memperbarui nilai total item dalam ke basket, dan mengirim data ke basket ke layanan mikro ke basket, seperti yang ditunjukkan dalam contoh kode berikut:

private async Task ReCalculateTotalAsync()
{
    // Omitted for brevity...

    await _basketService.UpdateBasketAsync(
        new CustomerBasket
        {
            BuyerId = userInfo.UserId, 
            Items = BasketItems.ToList()
        }, 
        authToken);
}

Metode ini memanggil metode BasketService instans yang disuntikkan UpdateBasketAsync ke dalam BasketViewModel oleh kontainer injeksi dependensi. Metode berikut menunjukkan UpdateBasketAsync metode :

public async Task<CustomerBasket> UpdateBasketAsync(
    CustomerBasket customerBasket, string token)
{
    UriBuilder builder = new UriBuilder(GlobalSetting.Instance.BasketEndpoint);
    string uri = builder.ToString();
    var result = await _requestProvider.PostAsync(uri, customerBasket, token);
    return result;
}

Metode ini membangun URI yang mengidentifikasi sumber daya yang akan dikirim permintaan, dan menggunakan RequestProvider kelas untuk memanggil metode HTTP POST pada sumber daya, sebelum mengembalikan hasilnya BasketViewModelke . Perhatikan bahwa token akses, yang diperoleh dari IdentityServer selama proses autentikasi, diperlukan untuk mengotorisasi permintaan ke layanan mikro kerak. Untuk informasi selengkapnya tentang otorisasi, lihat Otorisasi.

Contoh kode berikut menunjukkan salah PostAsync satu metode di RequestProvider kelas :

public async Task<TResult> PostAsync<TResult>(
    string uri, TResult data, string token = "", string header = "")
{
    HttpClient httpClient = GetOrCreateHttpClient(token);

    var content = new StringContent(JsonSerializer.Serialize(data));
    content.Headers.ContentType = new MediaTypeHeaderValue("application/json");
    HttpResponseMessage response = await httpClient.PostAsync(uri, content);

    await HandleResponse(response);
    TResult result = await response.Content.ReadFromJsonAsync<TResult>();
    
    return result;
}

Metode ini memanggil GetOrCreateHttpClient metode , yang mengembalikan instans HttpClient kelas dengan kumpulan header yang sesuai. Kemudian mengirimkan permintaan POST asinkron ke sumber daya yang diidentifikasi oleh URI, dengan data keraket serial dikirim dalam format JSON, dan respons disimpan dalam HttpResponseMessage instans. Metode HandleResponse ini kemudian dipanggil, yang melemparkan pengecualian jika respons tidak menyertakan kode status HTTP yang berhasil. Kemudian, respons dibaca sebagai string, dikonversi dari JSON ke CustomerBasket objek, dan dikembalikan ke BasketService. Untuk informasi selengkapnya tentang metode ini GetOrCreateHttpClient , lihat Membuat permintaan GET.

PostAsync Ketika metode di RequestProvider kelas memanggil HttpClient.PostAsync, Post metode di BasketController kelas dalam Basket.API proyek dipanggil, yang ditampilkan dalam contoh kode berikut:

[HttpPost]
public async Task<IActionResult> Post([FromBody] CustomerBasket value)
{
    var basket = await _repository.UpdateBasketAsync(value);
    return Ok(basket);
} 

Metode ini menggunakan instans RedisBasketRepository kelas untuk mempertahankan data ke basket ke cache Redis, dan mengembalikannya sebagai pesan respons yang menyertakan kode status HTTP yang berhasil, dan instans berformat CustomerBasket JSON.

Membuat permintaan DELETE

Gambar di bawah ini menunjukkan interaksi kelas yang menghapus data ke basket dari layanan mikro keramaian, untuk CheckoutView.

Ketika proses checkout dipanggil, CheckoutAsync metode di kelas dipanggil CheckoutViewModel . Metode ini membuat pesanan baru, sebelum membersihkan kerang belanja, seperti yang ditunjukkan dalam contoh kode berikut:

private async Task CheckoutAsync()
{
    // Omitted for brevity...

    await _basketService.ClearBasketAsync(
        _shippingAddress.Id.ToString(), authToken);
}

Metode ini memanggil metode BasketService instans yang disuntikkan ClearBasketAsync ke dalam CheckoutViewModel oleh kontainer injeksi dependensi. Metode berikut menunjukkan ClearBasketAsync metode :

public async Task ClearBasketAsync(string guidUser, string token)
{
    UriBuilder builder = new(GlobalSetting.Instance.BasketEndpoint);
    builder.Path = guidUser;
    string uri = builder.ToString();
    await _requestProvider.DeleteAsync(uri, token);
}

Metode ini membangun URI yang mengidentifikasi sumber daya tempat permintaan akan dikirim, dan menggunakan RequestProvider kelas untuk memanggil DELETE metode HTTP pada sumber daya. Perhatikan bahwa token akses, yang diperoleh dari IdentityServer selama proses autentikasi, diperlukan untuk mengotorisasi permintaan ke layanan mikro kerak. Untuk informasi selengkapnya tentang otorisasi, lihat Otorisasi.

Contoh kode berikut menunjukkan DeleteAsync metode di RequestProvider kelas :

public async Task DeleteAsync(string uri, string token = "")
{
    HttpClient httpClient = GetOrCreateHttpClient(token);
    await httpClient.DeleteAsync(uri);
}

Metode ini memanggil GetOrCreateHttpClient metode , yang mengembalikan instans HttpClient kelas dengan kumpulan header yang sesuai. Kemudian mengirimkan permintaan asinkron DELETE ke sumber daya yang diidentifikasi oleh URI. Untuk informasi selengkapnya tentang metode ini GetOrCreateHttpClient , lihat Membuat permintaan GET.

DeleteAsync Ketika metode di RequestProvider kelas memanggil HttpClient.DeleteAsync, Delete metode di BasketController kelas dalam Basket.API proyek dipanggil, yang ditampilkan dalam contoh kode berikut:

[HttpDelete("{id}")]
public void Delete(string id) =>
    _repository.DeleteBasketAsync(id);

Metode ini menggunakan instans RedisBasketRepository kelas untuk menghapus data ke basket dari cache Redis.

Cache data

Performa aplikasi dapat ditingkatkan dengan penembolokan data yang sering diakses ke penyimpanan cepat yang terletak dekat dengan aplikasi. Jika penyimpanan cepat terletak lebih dekat ke aplikasi daripada sumber aslinya, maka penembolokan dapat secara signifikan meningkatkan waktu respons saat mengambil data.

Bentuk penembolokan yang paling umum adalah penembolokan baca-melalui, di mana aplikasi mengambil data dengan merujuk cache. Jika data tidak ada dalam cache, data diambil dari penyimpanan data dan ditambahkan ke cache. Aplikasi dapat menerapkan penembolokan baca-melalui dengan pola cache-aside. Pola ini menentukan apakah item saat ini berada dalam cache. Jika item tidak ada di cache, item dibaca dari penyimpanan data dan ditambahkan ke cache. Untuk informasi selengkapnya, lihat pola Cache-Aside di Microsoft Docs.

Data ini dapat ditambahkan ke cache sesuai permintaan saat pertama kali diambil oleh aplikasi. Ini berarti bahwa aplikasi perlu mengambil data hanya sekali dari penyimpanan data, dan akses berikutnya dapat dipenuhi dengan menggunakan cache.

Aplikasi terdistribusi, seperti aplikasi referensi eShop, harus menyediakan salah satu atau kedua cache berikut:

• Cache bersama, yang dapat diakses oleh beberapa proses atau mesin.
• Cache privat, tempat data disimpan secara lokal di perangkat yang menjalankan aplikasi.

Aplikasi multi-platform eShop menggunakan cache privat, di mana data disimpan secara lokal di perangkat yang menjalankan instans aplikasi.

Pastikan bahwa data dipertahankan di penyimpanan data asli serta cache. Kemungkinan kehilangan data kemudian diminimalkan jika cache menjadi tidak tersedia.

Mengelola kedaluwarsa data

Tidak praktis untuk mengharapkan bahwa data yang di-cache akan selalu konsisten dengan data asli. Data di penyimpanan data asli mungkin berubah setelah di-cache, menyebabkan data yang di-cache menjadi basi. Oleh karena itu, aplikasi harus menerapkan strategi yang membantu memastikan bahwa data dalam cache seperbarui mungkin, tetapi juga dapat mendeteksi dan menangani situasi yang muncul ketika data di cache telah kedaluarsa. Sebagian besar mekanisme penembolokan memungkinkan cache dikonfigurasi untuk kedaluwarsa data, dan karenanya mengurangi periode data yang mungkin kedaluwarsa.

Banyak cache menerapkan kedaluwarsa, yang membatalkan data dan menghapusnya dari cache jika tidak diakses untuk periode tertentu. Namun, perawatan harus diambil ketika memilih periode kedaluwarsa. Jika dibuat terlalu singkat, data akan kedaluwarsa terlalu cepat dan manfaat penembolokan akan berkurang. Jika dibuat terlalu lama, risiko data menjadi basi. Oleh karena itu, waktu kedaluwarsa harus sesuai dengan pola akses untuk aplikasi yang menggunakan data.

Ketika data yang di-cache kedaluwarsa, data harus dihapus dari cache, dan aplikasi harus mengambil data dari penyimpanan data asli dan menempatkannya kembali ke cache.

Ada kemungkinan juga bahwa cache mungkin terisi jika data diizinkan untuk tetap terlalu lama. Oleh karena itu, permintaan untuk menambahkan item baru ke cache mungkin diperlukan untuk menghapus beberapa item dalam proses yang dikenal sebagai pengeluaran. Layanan penembolokan biasanya mengeluarkan data berdasarkan yang paling tidak baru-baru ini digunakan. Namun, ada kebijakan pengeluaran lainnya, termasuk yang paling baru digunakan, dan first-in-first-out. Untuk informasi selengkapnya, lihat Panduan Penembolokan di Microsoft Docs.

Gambar penembolokan

Aplikasi multi-platform eShop mengonsumsi gambar produk jarak jauh yang mendapat manfaat dari di-cache. Gambar-gambar ini ditampilkan oleh kontrol Gambar. Kontrol Gambar .NET MAUI mendukung penembolokan gambar yang diunduh yang memiliki penembolokan yang diaktifkan secara default, dan akan menyimpan gambar secara lokal selama 24 jam. Selain itu, waktu kedaluwarsa dapat dikonfigurasi dengan properti CacheValidity. Untuk informasi selengkapnya, lihat Penembolokan Gambar yang Diunduh di Pusat Pengembang Microsoft.

Meningkatkan ketahanan

Semua aplikasi yang berkomunikasi dengan layanan dan sumber daya jarak jauh harus sensitif terhadap kesalahan sementara. Kesalahan sementara termasuk hilangnya konektivitas jaringan sesaat ke layanan, tidak tersedianya sementara layanan, atau batas waktu yang muncul ketika layanan sibuk. Kesalahan ini sering kali mengoreksi diri sendiri, dan jika tindakan diulang setelah penundaan yang sesuai, kemungkinan akan berhasil.

Kesalahan sementara dapat berdampak besar pada kualitas aplikasi yang dirasakan, bahkan jika telah diuji secara menyeluruh dalam semua keadaan yang dapat diperkirakan. Untuk memastikan bahwa aplikasi yang berkomunikasi dengan layanan jarak jauh beroperasi dengan andal, aplikasi harus dapat melakukan semua hal berikut:

• Deteksi kesalahan ketika terjadi, dan tentukan apakah kesalahan kemungkinan bersifat sementara.
• Coba lagi operasi jika menentukan bahwa kesalahan kemungkinan bersifat sementara dan melacak berapa kali operasi dicoba kembali.
• Gunakan strategi coba lagi yang sesuai, yang menentukan jumlah percobaan ulang, penundaan antara setiap upaya, dan tindakan yang harus diambil setelah upaya yang gagal.

Penanganan kesalahan sementara ini dapat dicapai dengan membungkus semua upaya untuk mengakses layanan jarak jauh dalam kode yang menerapkan pola coba lagi.

Pola coba lagi

Jika aplikasi mendeteksi kegagalan saat mencoba mengirim permintaan ke layanan jarak jauh, aplikasi dapat menangani kegagalan dengan salah satu cara berikut:

• Mencoba kembali operasi. Aplikasi dapat segera mencoba kembali permintaan yang gagal.
• Mencoba kembali operasi setelah penundaan. Aplikasi harus menunggu jumlah waktu yang sesuai sebelum mencoba kembali permintaan.
• Membatalkan operasi. Aplikasi harus membatalkan operasi dan melaporkan pengecualian.

Strategi coba lagi harus disetel agar sesuai dengan persyaratan bisnis aplikasi. Misalnya, penting untuk mengoptimalkan jumlah coba lagi dan mencoba kembali interval ke operasi yang sedang dicoba. Jika operasi adalah bagian dari interaksi pengguna, interval coba lagi harus singkat dan hanya beberapa percobaan ulang yang mencoba menghindari membuat pengguna menunggu respons. Jika operasi adalah bagian dari alur kerja yang berjalan lama, di mana membatalkan atau memulai ulang alur kerja mahal atau memakan waktu, sebaiknya tunggu lebih lama antara upaya dan untuk mencoba kembali lebih banyak kali.

Jika permintaan masih gagal setelah sejumlah percobaan ulang, lebih baik aplikasi mencegah permintaan lebih lanjut masuk ke sumber daya yang sama dan melaporkan kegagalan. Kemudian, setelah periode yang ditetapkan, aplikasi dapat membuat satu atau beberapa permintaan ke sumber daya untuk melihat apakah berhasil. Untuk informasi selengkapnya, lihat Pola pemutus sirkuit.

Gunakan jumlah percobaan ulang yang terbatas, atau terapkan pola Circuit Breaker untuk memungkinkan layanan pulih.

Aplikasi referensi eShop memang menerapkan pola coba lagi.

Untuk informasi selengkapnya tentang pola coba lagi, lihat pola Coba lagi di Microsoft Docs.

Pola pemutus sirkuit

Dalam beberapa situasi, kesalahan dapat terjadi karena peristiwa yang diantisipasi yang membutuhkan waktu lebih lama untuk diperbaiki. Kesalahan ini dapat berkisar dari hilangnya sebagian konektivitas hingga kegagalan lengkap layanan. Dalam situasi ini, tidak ada gunanya aplikasi mencoba kembali operasi yang tidak mungkin berhasil, dan sebaliknya harus menerima bahwa operasi telah gagal dan menangani kegagalan ini.

Pola pemutus sirkuit dapat mencegah aplikasi berulang kali mencoba menjalankan operasi yang kemungkinan gagal, sekaligus memungkinkan aplikasi mendeteksi apakah kesalahan telah diselesaikan.

Pemutus sirkuit bertindak sebagai proxy untuk operasi yang mungkin gagal. Proksi harus memantau jumlah kegagalan terbaru yang terjadi, dan menggunakan informasi ini untuk memutuskan apakah akan memungkinkan operasi dilanjutkan, atau segera mengembalikan pengecualian.

Aplikasi multi-platform eShop saat ini tidak menerapkan pola pemutus sirkuit. Namun, eShop melakukannya.

Aplikasi dapat menggabungkan pola pemutus coba lagi dan pemutus sirkuit dengan menggunakan pola coba lagi untuk memanggil operasi melalui pemutus sirkuit. Namun, percobaan ulang logika harus peka terhadap pengecualian yang dikembalikan oleh pemutus sirkuit dan meninggalkan upaya coba ulang jika pemutus sirkuit menunjukkan bahwa kesalahan tidak bersifat sementara.

Untuk informasi selengkapnya tentang pola pemutus sirkuit, lihat pola Circuit Breaker di Microsoft Docs.

Ringkasan

Banyak solusi berbasis web modern memanfaatkan layanan web, yang dihosting oleh server web, untuk menyediakan fungsionalitas untuk aplikasi klien jarak jauh. Operasi yang diekspos layanan web merupakan API web, dan aplikasi klien harus dapat menggunakan API web tanpa mengetahui bagaimana data atau operasi yang diimplementasikan API.

Performa aplikasi dapat ditingkatkan dengan penembolokan data yang sering diakses ke penyimpanan cepat yang terletak dekat dengan aplikasi. Aplikasi dapat menerapkan penembolokan baca-melalui dengan pola cache-aside. Pola ini menentukan apakah item saat ini berada dalam cache. Jika item tidak ada di cache, item dibaca dari penyimpanan data dan ditambahkan ke cache.

Saat berkomunikasi dengan API web, aplikasi harus sensitif terhadap kesalahan sementara. Kesalahan sementara termasuk hilangnya konektivitas jaringan sesaat ke layanan, tidak tersedianya sementara layanan, atau batas waktu yang muncul ketika layanan sibuk. Kesalahan ini sering kali mengoreksi diri sendiri, dan jika tindakan diulang setelah penundaan yang sesuai, kemungkinan akan berhasil. Oleh karena itu, aplikasi harus membungkus semua upaya untuk mengakses API web dalam kode yang menerapkan mekanisme penanganan kesalahan sementara.