Bagikan melalui

Dukungan penembolokan untuk layanan HTTP web WCF

  • Artikel

.NET Framework 4.6.1 memungkinkan Anda untuk menggunakan mekanisme pembuatan cache deklaratif yang sudah tersedia di ASP.NET di layanan Web HTTP WCF Anda. Mekanisme ini memungkinkan Anda untuk menyimpan respons dari operasi layanan HTTP Web WCF Anda. Saat pengguna mengirim HTTP GET ke layanan Anda yang dikonfigurasi untuk penembolokan, ASP.NET mengirim kembali respons yang di-cache dan metode layanan tidak dipanggil. Ketika cache kedaluwarsa, saat pengguna mengirim HTTP GET, metode layanan Anda dipanggil dan respons sekali lagi di-cache. Untuk informasi selengkapnya tentang pembuatan cache ASP.NET, lihat Ringkasan Pembuatan Cache ASP.NET.

Pembuatan Cache Layanan Web HTTP Dasar

Untuk mengaktifkan pembuatan cache layanan WEB HTTP, Anda harus terlebih dahulu mengaktifkan kompatibilitas ASP.NET dengan menerapkan AspNetCompatibilityRequirementsAttribute ke pengaturan layanan RequirementsMode menjadi Allowed atau Required.

.NET Framework 4 memperkenalkan atribut baru yang disebut AspNetCacheProfileAttribute yang memungkinkan Anda menentukan nama profil cache. Atribut ini diterapkan ke operasi layanan. Contoh berikut menerapkan AspNetCompatibilityRequirementsAttribute ke layanan untuk mengaktifkan kompatibilitas ASP.NET dan mengonfigurasi operasi GetCustomer untuk pembuatan cache. Atribut AspNetCacheProfileAttribute menentukan profil cache yang berisi pengaturan cache yang akan digunakan.

[ServiceContract]
[AspNetCompatibilityRequirements(RequirementsMode=AspNetCompatibilityRequirementsMode.Allowed)]
public class Service
{
    [WebGet(UriTemplate = "{id}")]
    [AspNetCacheProfile("CacheFor60Seconds")]
    public Customer GetCustomer(string id)
    {
        // ...
    }
}

Aktifkan juga mode kompatibilitas ASP.NET dalam file Web.config seperti yang ditunjukkan pada contoh berikut.

<system.serviceModel>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>

Peringatan

Jika mode kompatibilitas ASP.NET tidak diaktifkan dan AspNetCacheProfileAttribute digunakan maka pengecualian akan dilemparkan.

Nama profil cache yang ditentukan oleh AspNetCacheProfileAttribute mengidentifikasi profil cache yang ditambahkan ke file konfigurasi Web.config Anda. Profil cache didefinisikan dengan dalam elemen <outputCacheSetting> seperti yang ditunjukkan dalam contoh konfigurasi berikut.

<!-- ... -->
<system.web>
   <caching>
      <outputCacheSettings>
         <outputCacheProfiles>
            <add name="CacheFor60Seconds" duration="60" varyByParam="none" sqlDependency="MyTestDatabase:MyTable"/>
         </outputCacheProfiles>
      </outputCacheSettings>
   </caching>
   <!-- ... -->
</system.web>

Ini adalah elemen konfigurasi yang sama yang tersedia untuk aplikasi ASP.NET. Untuk informasi selengkapnya tentang profil cache ASP.NET, lihat OutputCacheProfile. Untuk layanan Web HTTP, atribut terpenting dalam profil cache adalah: cacheDuration dan varyByParam. Kedua atribut tersebut diperlukan. cacheDuration mengatur jumlah waktu respons seharusnya di-cache dalam hitungan detik. varyByParam memungkinkan Anda menentukan parameter string kueri yang digunakan untuk men-cache respons. Semua permintaan yang dibuat dengan nilai parameter string kueri yang berbeda akan di-cache secara terpisah. Misalnya, setelah permintaan awal dibuat ke http://MyServer/MyHttpService/MyOperation?param=10, semua permintaan berikutnya yang dibuat dengan URI yang sama akan menampilkan respons cache (selama durasi cache belum berlalu). Tanggapan untuk permintaan serupa yang sama tetapi memiliki nilai berbeda untuk parameter string kueri parameter di-cache secara terpisah. Jika Anda tidak ingin perilaku pembuatan cache terpisah ini, atur varyByParam ke "none".

Dependensi Cache SQL

Respons layanan Web HTTP juga dapat di-cache dengan dependensi cache SQL. Jika layanan HTTP Web WCF Anda bergantung pada data yang disimpan dalam database SQL, Anda mungkin ingin menyimpan respons layanan dan membatalkan respons cache saat data dalam tabel database SQL berubah. Perilaku ini dikonfigurasi sepenuhnya dalam file Web.config. Pertama-tama, tentukan string koneksi dalam elemen <connectionStrings>.

<connectionStrings>
  <add name="connectString"
       connectionString="..."
       providerName="System.Data.SqlClient" />
</connectionStrings>

Kemudian, aktifkan dependensi cache SQL dalam <caching> elemen dalam <system.web> elemen seperti yang ditunjukkan dalam contoh konfigurasi berikut.

<system.web>
  <caching>
    <sqlCacheDependency enabled="true" pollTime="1000">
      <databases>
        <add name="MyTestDatabase" connectionStringName="connectString" />
      </databases>
    </sqlCacheDependency>
    <!-- ... -->
  </caching>
  <!-- ... -->
</system.web>

Di sini, dependensi cache SQL diaktifkan dan waktu polling 1000 milidetik diatur. Setiap kali waktu polling berlalu, tabel database diperiksa untuk pembaruan. Jika perubahan terdeteksi, konten cache akan dihapus dan di waktu berikutnya operasi layanan dipanggil, respons baru akan di-cache. Dalam elemen <sqlCacheDependency>, tambahkan database dan referensikan string koneksi dalam elemen <databases> seperti yang ditunjukkan dalam contoh berikut.

<system.web>
  <caching>
    <sqlCacheDependency enabled="true" pollTime="1000">
      <databases>
        <add name="MyTestDatabase" connectionStringName="connectString" />
      </databases>
    </sqlCacheDependency>
    <!-- ... -->
  </caching>
  <!-- ... -->
</system.web>

Selanjutnya Anda harus mengonfigurasi pengaturan cache output dalam elemen <caching> seperti yang ditunjukkan dalam contoh berikut.

<system.web>
  <caching>
    <!-- ... -->
    <outputCacheSettings>
      <outputCacheProfiles>
        <add name="CacheFor60Seconds" duration="60" varyByParam="none" sqlDependency="MyTestDatabase:MyTable" />
      </outputCacheProfiles>
    </outputCacheSettings>
  </caching>
  <!-- ... -->
</system.web>

Di sini, durasi cache diatur ke 60 detik, varyByParam diatur ke none, dan sqlDependency diatur ke daftar yang dibatasi titik koma berisi pasangan nama/tabel database yang dipisahkan oleh titik dua. Saat data di MyTable diubah, respons yang di-cache untuk operasi layanan akan dihapus dan ketika operasi dipanggil, respons baru akan dihasilkan (dengan memanggil operasi layanan), di-cache, dan ditampilkan ke klien.

Penting

Agar ASP.NET mengakses database SQL, Anda harus menggunakan Alat Pendaftaran SQL Server ASP.NET. Selain itu, Anda harus mengizinkan akses akun pengguna yang sesuai ke database dan tabel. Untuk informasi selengkapnya, lihat Mengakses SQL Server dari Aplikasi Web.

Pembuatan Cache Berbasis HTTP GET Kondisional

Dalam skenario Web HTTP, permintaan HTTP GET kondisional sering digunakan oleh layanan untuk menerapkan pembuatan cache HTTP cerdas seperti yang dijelaskan dalam Spesifikasi HTTP. Untuk melakukan ini, layanan harus mengatur nilai header ETag dalam respons HTTP. Layanan itu juga harus memeriksa header If-None-Match dalam permintaan HTTP untuk melihat apakah salah satu ETag yang ditentukan cocok dengan ETag saat ini.

Untuk permintaan GET dan HEAD, CheckConditionalRetrieve menggunakan nilai ETag dan memeriksanya terhadap header If-None-Match dari permintaan. Jika header ada dan cocok, WebFaultException dengan kode status HTTP 304 (Tidak Dimodifikasi) akan dilemparkan dan header ETag ditambahkan ke respons dengan ETag yang cocok.

Satu kelebihan beban metode CheckConditionalRetrieve menggunakan tanggal modifikasi terakhir dan memeriksanya terhadap header If-Modified-Since dari permintaan. Jika header ada dan sumber daya belum dimodifikasi, WebFaultException dengan kode status HTTP 304 (Tidak Dimodifikasi) akan dilemparkan.

Untuk permintaan PUT, POST, dan DELETE, CheckConditionalUpdate menggunakan nilai ETag saat ini dari sumber daya. Jika nilai ETag saat ini null, metode akan memeriksa bahwa header If-None- Match memiliki nilai "*". Jika nilai ETag saat ini bukan nilai default, maka metode memeriksa nilai ETag saat ini terhadap header If- Match dari permintaan. Dalam kedua kasus, metode akan melempar WebFaultException dengan kode status HTTP 412 (Prasyarat Gagal) jika header yang diharapkan tidak ada dalam permintaan atau nilainya tidak memenuhi pemeriksaan kondisional dan mengatur header ETag dari respons ke nilai ETag saat ini.

Metode CheckConditional dan SetETag memastikan bahwa nilai ETag yang ditetapkan pada header respons adalah ETag yang valid sesuai dengan spesifikasi HTTP. Hal ini termasuk memberi nilai ETag tanda kutip ganda jika belum ada dan keluar secara benar dari karakter kutipan ganda internal. Perbandingan ETag lemah tidak didukung.

Contoh berikut menunjukkan cara menggunakan metode berikut.

[WebGet(UriTemplate = "{id}"), Description("Returns the specified customer from customers collection. Returns NotFound if there is no such customer. Supports conditional GET.")]
public Customer GetCustomer(string id)
{
    lock (writeLock)
    {
        // return NotFound if there is no item with the specified id.
        object itemEtag = customerEtags[id];
        if (itemEtag == null)
        {
            throw new WebFaultException(HttpStatusCode.NotFound);
        }

        // return NotModified if the client did a conditional GET and the customer item has not changed
        // since when the client last retrieved it
        WebOperationContext.Current.IncomingRequest.CheckConditionalRetrieve((long)itemEtag);
        Customer result = this.customers[id] as Customer;

        // set the customer etag before returning the result
        WebOperationContext.Current.OutgoingResponse.SetETag((long)itemEtag);
        return result;
    }
}

Pertimbangan Keamanan

Permintaan yang memerlukan otorisasi tidak boleh men-cache tanggapannya, karena otorisasi tidak dilakukan ketika respons dilayani dari cache. Pembuatan cache tanggapan tersebut akan menyebabkan kerentanan keamanan yang serius. Biasanya, permintaan yang memerlukan otorisasi menyediakan data khusus pengguna dan oleh karena itu pembuatan cache sisi server bahkan tidak menguntungkan. Dalam situasi seperti itu, penembolokan sisi klien atau hanya tidak melakukan penembolokan sama sekali lebih tepat.