Azure REST API başvurusu

Azure REST API başvuru belgelerine hoş geldiniz.

Temsili Durum Aktarımı (REST) API'leri; hizmet kaynaklarına oluşturma, alma, güncelleştirme veya silme erişimi sağlayan HTTP işlem kümelerini (yöntemler) destekleyen hizmet uç noktalarıdır. Bu makalede size yol gösterebilirsiniz:

  • Curl ile Azure REST API'lerini çağırma
  • REST API istek/yanıt çiftinin temel bileşenleri.
  • REST isteklerinizin güvenliğini sağlamak için istemci uygulamanızı Microsoft Entra ID kaydetme.
  • REST isteği oluşturma ve gönderme ve yanıtı işlemeye genel bakış.

İpucu

Çoğu Azure hizmeti REST API'sinde, Azure hizmetlerini kullanmak için yerel arabirim sağlayan istemci kitaplıkları vardır:

.NET | Java | | Node.jsPython | Git | C++

Curl ile Azure REST API'lerini çağırma

Aşağıdaki blog gönderisinde açıklanan işlem, curl kullanarak Azure REST API'sini çağırmayı göstermektedir. Katılımsız betiklerde curl kullanmayı düşünebilirsiniz. Örneğin, DevOps otomasyon senaryolarında.

Curl aracılığıyla Azure REST API'yi çağırma

REST API istek/yanıt bileşenleri

REST API istek/yanıt çifti beş bileşene ayrılabilir:

  1. İstek URI'si, şu şekildedir: {URI-scheme} :// {URI-host} / {resource-path} ? {query-string}. İstek URI'si istek iletisi üst bilgilerinde yer alsa da birçok dil veya çerçeve için bunu istek iletisinden ayrı bir şekilde iletmeniz gerektiğinden burada ayrı ele alıyoruz.

    • URI şeması: İsteği iletmek için kullanılan protokolü belirtir. Örneğin http veya https olabilir.
    • URI ana bilgisayarı: REST hizmeti uç noktasının barındırıldığı sunucunun etki alanı adını veya IP adresini belirtir, örneğin: graph.microsoft.com.
    • Kaynak yolu: Kaynağı veya hizmetin kaynak seçimine karar vermek için kullandığı birden fazla bölüm içerebilen kaynak koleksiyonunu belirtir. Örneğin: beta/applications/00003f25-7e1f-4278-9488-efc7bac53c4a/owners uygulama koleksiyonundaki belirli bir uygulamanın sahiplerini listelemek için kullanılabilir.
    • Sorgu dizesi (isteğe bağlı): API sürümü veya kaynak seçim ölçütü gibi basit ek parametreler sunar.
  2. HTTP isteği ileti üst bilgisi alanları:

    • Hizmete ne tür bir işlem istediğinizi bildiren gerekli bir HTTP yöntemi (işlem veya fiil olarak da bilinir). Azure REST API'leri GET, HEAD, PUT, POST ve PATCH yöntemlerini destekler.
    • Belirtilen URI ve HTTP yöntemi için gerekli olan isteğe bağlı üst bilgi alanları. Örneğin, istek için istemci yetkilendirme bilgilerini içeren taşıyıcı belirteci sağlayan bir Yetkilendirme üst bilgisi.
  3. URI ve HTTP işlemini destekleyecek isteğe bağlı HTTP istek iletisi gövdesi alanları. Örneğin POST işlemleri, karmaşık parametreler olarak iletilen MIME kodlamalı nesneler içerir. POST veya PUT işlemleri için gövde MIME kodlama türü de Content-type istek üst bilgisinde belirtilmelidir. Bazı hizmetlerde application/json gibi belirli bir MIME türü kullanılması gerekir.

  4. HTTP yanıt iletisi üst bilgi alanları:

    • 2xx başarı kodlarından 4xx veya 5xx hata kodlarına kadar değişebilen bir HTTP durum kodu. Alternatif olarak API belgelerinde belirtildiği şekilde hizmet tarafından tanımlanan bir durum kodu da döndürülebilir.
    • İsteğin yanıtını desteklemek için Content-type yanıt üst bilgisi gibi isteğe bağlı ek üst bilgi alanları.
  5. İsteğe bağlı HTTP yanıt iletisi gövdesi alanları:

    • Veri döndüren GET yöntemi yanıtı gibi MIME kodlamalı yanıt nesneleri, HTTP yanıt gövdesinde döndürülür. Bu nesneler genellikle JSON veya XML gibi yapılandırılmış biçimde döndürülür ve bu durum Content-type yanıt üst bilgisi ile belirtilir. Örneğin, Microsoft Entra ID erişim belirteci istediğinizde, yanıt gövdesinde veri koleksiyonundaki birkaç ad/değer eşleştirilmiş nesneden biri olan öğesi olarak access_token döndürülür. Bu örnekte, yanıt üst bilgisi Content-Type: application/json de eklenmiştir.

İstemci uygulamanızı Microsoft Entra ID kaydetme

Çoğu Azure hizmeti (Azure Resource Manager sağlayıcıları ve klasik dağıtım modeli gibi), hizmetin API'sini çağırabilmeniz için istemci kodunuzun geçerli kimlik bilgileriyle kimlik doğrulaması gerçekleştirmesini gerektirir. Kimlik doğrulaması, Microsoft Entra ID tarafından çeşitli aktörler arasında koordine edilir ve istemcinize kimlik doğrulamasının kanıtı olarak bir erişim belirteci sağlar. Ardından belirteç, sonraki REST API isteklerinin HTTP Yetkilendirme üst bilgisinde Azure hizmetine gönderilir. Belirtecin talepleri ayrıca hizmete bilgi sağlayarak istemciyi doğrulamasını ve gerekli yetkilendirmeyi gerçekleştirmesini sağlar.

Tümleşik Microsoft Entra kimlik doğrulaması kullanmayan bir REST API kullanıyorsanız veya istemcinizi zaten kaydettiyseniz İstek oluşturma bölümüne atlayın.

Önkoşullar

İstemci uygulamanızın kimlik yapılandırmasını çalışma zamanından önce Microsoft Entra bir kiracıya kaydederek Microsoft Entra ID olarak bilinen hale getirmesi gerekir. İstemcinizi Microsoft Entra ID kaydetmeden önce aşağıdaki önkoşulları göz önünde bulundurun:

  • Henüz bir Microsoft Entra kiracınız yoksa bkz. Microsoft Entra kiracı ayarlama.

  • OAuth2 Yetkilendirme Çerçevesi uyarınca, Microsoft Entra ID iki tür istemciyi destekler. Bunların her biri, senaryonuz için en uygun olan senaryoya karar vermenize yardımcı olur:

    • web/gizli istemciler bir web sunucusunda çalışır ve kendi kimlikleri (örneğin, bir hizmet veya daemon) altındaki kaynaklara erişebilir veya oturum açmış bir kullanıcının kimliği (örneğin, bir web uygulaması) altında kaynaklara erişmek için temsilci yetkilendirmesi alabilir. Yalnızca bir web istemcisi, erişim belirteci almak için Microsoft Entra kimlik doğrulaması sırasında kendi kimlik bilgilerini güvenli bir şekilde koruyabilir ve sunabilir.
    • yerel/genel istemciler bir cihazda yüklenir ve çalıştırılır. Oturum açmış kullanıcının kimliğini kullanarak, kullanıcı adına erişim belirteci almak için kaynaklara yalnızca temsilci yetkilendirmesi altında erişebilirler.
  • Kayıt işlemi, uygulamanın kaydedildiği Microsoft Entra kiracısında iki ilgili nesne oluşturur: uygulama nesnesi ve hizmet sorumlusu nesnesi. Bu bileşenler ve çalışma zamanında nasıl kullanıldıkları hakkında daha fazla bilgi için bkz. Microsoft Entra ID'de uygulama ve hizmet sorumlusu nesneleri.

Artık istemci uygulamanızı Microsoft Entra ID kaydetmeye hazırsınız.

İstemci kaydı

Azure Resource Manager REST API'sine erişen bir istemciyi kaydetmek için bkz. Kaynaklara erişebilen Microsoft Entra uygulama ve hizmet sorumlusu oluşturmak için portalı kullanma. Makalede (kaydı otomatikleştirmek için PowerShell ve CLI sürümlerinde de kullanılabilir) şunların nasıl yapılacağını gösterir:

  • İstemci uygulamasını Microsoft Entra ID kaydedin.
  • İstemcinin Azure Resource Manager API'sine erişmesine izin vermek için izin isteklerini ayarlayın.
  • İstemciyi yetkilendirmek için Azure Resource Manager Role-Based Access Control (RBAC) ayarlarını yapılandırın.

İstemciniz Azure Resource Manager API'sinden başka bir API'ye erişiyorsa bkz:

İstemci uygulamanızın kaydını tamamladığınıza göre, REST isteğini oluşturduğunuz ve yanıtı işlediğiniz istemci koduna geçin.

İsteği oluşturma

Bu bölümde, daha önce ele aldığımız beş bileşenin ilk üçü ele alınıyor. İlk olarak, istek iletisi üst bilginizi bir araya getirmek için kullandığınız Microsoft Entra ID erişim belirtecini almanız gerekir.

Erişim belirteci alma

Geçerli bir istemci kaydınız olduktan sonra, erişim belirteci almak için Microsoft Entra ID ile tümleştirmenin iki yolu vardır:

  • Bu makalede kullandığımız platform ve dilden bağımsız OAuth2 hizmet uç noktaları. Bu bölümde sağlanan yönergelerde, Microsoft Entra OAuth uç noktalarını kullandığınızda istemcinizin platformu veya dili/betiği hakkında hiçbir şey varsayılır. Tek gereksinim, https isteklerini Microsoft Entra ID gönderebilmeniz/alabilmeniz ve yanıt iletisini ayrıştırabilmenizdir.
  • Platforma ve dile özgü Microsoft Kimlik Doğrulama Kitaplıkları (MSAL), bu makalenin kapsamı dışındadır. Kitaplıklar, OAuth2 uç nokta istekleri için zaman uyumsuz sarmalayıcılar ve önbelleğe alma ve yenileme belirteci yönetimi gibi güçlü belirteç işleme özellikleri sağlar. Daha fazla bilgi için bkz. Microsoft Authentication Library'ye (MSAL) Genel Bakış.

İstemcinizin kimliğini doğrulamak ve erişim belirteci almak için kullandığınız iki Microsoft Entra uç noktası, OAuth2 /authorize ve /token uç noktalar olarak adlandırılır. Bunları nasıl kullanacağınız, uygulamanızın kaydına ve çalışma zamanında uygulamanızı desteklemek için ihtiyacınız olan OAuth2 yetkilendirme verme akışının türüne bağlıdır. Bu makalenin amaçları doğrultusunda, istemcinizin aşağıdaki yetkilendirme verme akışlarından birini kullandığını varsayarız: yetkilendirme kodu veya istemci kimlik bilgileri. Kalan bölümlerde kullanılan bir erişim belirtecini almak için, senaryonuza en uygun akışın yönergelerini izleyin.

Yetkilendirme kodu verme (etkileşimli istemciler)

Bu izin hem web hem de yerel istemciler tarafından kullanılır ve istemci uygulamasına kaynak erişimi atamak için oturum açmış bir kullanıcıdan kimlik bilgileri gerekir. Bir yetkilendirme kodu (kullanıcı oturum açma/onayına yanıt olarak) almak için uç noktayı ve ardından /token erişim belirteci için yetkilendirme kodunu değiştirmek için uç noktayı kullanır/authorize.

  1. İlk olarak, istemcinizin Microsoft Entra ID'dan bir yetkilendirme kodu istemesi gerekir. Uç noktaya HTTPS GET isteğinin biçimi ve örnek istek/yanıt iletileri hakkında ayrıntılı bilgi için /authorize bkz. Yetkilendirme kodu isteme. URI, istemci uygulamanıza özgü aşağıdaki sorgu dizesi parametrelerini içerir:

    • client_id: Kayıt sırasında istemci uygulamanıza atanan ve uygulama kimliği olarak da bilinen GUID.

    • redirect_uri: İstemci uygulamanızın kaydı sırasında belirtilen yanıt/yeniden yönlendirme URI'lerinden birinin URL ile kodlanmış sürümü. Geçirdiğiniz değer kayıt değerinizle tam olarak eşleşmelidir.

    • resource: Çağırdığınız REST API tarafından belirtilen URL ile kodlanmış tanımlayıcı URI'si. Web/REST API'leri (kaynak uygulamaları olarak da bilinir) yapılandırmalarında bir veya daha fazla uygulama kimliği URI'sini kullanıma açabilir. Örnek:

      • Azure Resource Manager sağlayıcısı (ve klasik dağıtım modeli) API'leri kullanırhttps://management.core.windows.net/.
      • Diğer tüm kaynaklar için Azure portal API belgelerine veya kaynak uygulamasının yapılandırmasına bakın. Daha fazla bilgi için bkzidentifierUris. Microsoft Graph API uygulama nesnesinin özelliği.

    Uç noktaya yapılan /authorize istek, önce kullanıcının kimliğini doğrulamak için bir oturum açma istemi tetikler. Geri alabileceğiniz yanıt, içinde redirect_uribelirttiğiniz URI'ye yeniden yönlendirme (302) olarak teslim edilir. Yanıt üst bilgisi iletisi, yeniden yönlendirme URI'sini ve ardından bir sorgu parametresini içeren bir code alan içerirlocation. parametresi, code 2. adım için ihtiyacınız olan yetkilendirme kodunu içerir.

  2. Ardından, istemcinizin bir erişim belirteci için yetkilendirme kodunu kullanması gerekir. Uç noktaya HTTPS POST isteğinin /token biçimi ve istek/yanıt örnekleri için bkz. Erişim belirteci isteme. Bu bir POST isteği olduğundan, uygulamanıza özgü parametreleri istek gövdesinde paketlersiniz. Daha önce bahsedilen bazı parametrelere (diğer yeni parametrelerle birlikte) ek olarak şunları geçireceksiniz:

    • code: Bu sorgu parametresi, 1. adımda aldığınız yetkilendirme kodunu içerir.

    • client_secret: Bu parametreye yalnızca istemciniz bir web uygulaması olarak yapılandırılmışsa ihtiyacınız vardır. Bu, istemci kaydında daha önce oluşturduğunuz gizli dizi/anahtar değeriyle aynıdır.

İstemci kimlik bilgileri verme (etkileşimli olmayan istemciler)

Bu izin yalnızca web istemcileri tarafından kullanılır ve uygulamanın kayıt zamanında sağlanan istemci kimlik bilgilerini kullanarak kaynaklara doğrudan erişmesine (kullanıcı temsilcisi olmadan) izin verir. Verme genellikle bir hizmet veya daemon olarak çalışan etkileşimli olmayan istemciler (ui olmadan) tarafından kullanılır. Erişim belirteci almak için yalnızca /token uç noktayı gerektirir.

Bu iznin istemci/kaynak etkileşimleri, yetkilendirme kodu verme işleminin 2. adımına benzer. Uç noktaya HTTPS POST isteğinin /token biçimi ve istek/yanıt örnekleri hakkında ayrıntılı bilgi için Microsoft kimlik platformu ve OAuth 2.0 istemci kimlik bilgileri akışındaki "Belirteç alma" bölümüne bakın.

İstek iletisini derleme

Çoğu programlama dili veya çerçeve ve betik oluşturma ortamı, istek iletisini derlemeyi ve göndermeyi kolaylaştırır. Genellikle isteğin oluşturulmasını veya biçimlendirmesini soyutlayan bir web/HTTP sınıfı veya API sağlayarak istemci kodunun (HttpWebRequestörneğin, .NET Framework sınıfı) yazılmasını kolaylaştırır. Kısa olması ve görevin büyük bölümü sizin için işlendiğinden, bu bölüm isteğin yalnızca önemli öğelerini kapsar.

İstek URI'si

Hassas bilgiler aktarılıp alındığından, tüm REST istekleri URI şeması için HTTPS protokolü gerektirir ve istek ve yanıta güvenli bir kanal verir. Bilgiler (yani, Microsoft Entra yetkilendirme kodu, erişim/taşıyıcı belirteci ve hassas istek/yanıt verileri) daha düşük bir aktarım katmanıyla şifrelenir ve iletilerin gizliliğini sağlar.

Hizmetinizin istek URI'sinin geri kalanı (konak, kaynak yolu ve gerekli sorgu dizesi parametreleri) ilgili REST API belirtimine göre belirlenir. Örneğin, Azure Resource Manager sağlayıcı API'leri kullanır https://management.azure.com/ve Klasik Azure dağıtım modeli kullanırhttps://management.core.windows.net/. Her ikisi de bir api-version sorgu dizesi parametresi gerektirir.

İstek üst bilgisi

İstek URI'si, hizmetinizin REST API belirtimi ve HTTP belirtimi için gereken ek alanlarla birlikte istek iletisi üst bilgisinde paketlenir. İsteğiniz aşağıdaki ortak üst bilgi alanlarını gerektirebilir:

  • Authorization: daha önce Microsoft Entra ID edinilen isteğin güvenliğini sağlamak için OAuth2 taşıyıcı belirtecini içerir.
  • Content-Type: Genellikle "application/json" (JSON biçiminde ad/değer çiftleri) olarak ayarlanır ve istek gövdesinin MIME türünü belirtir.
  • Host: REST hizmet uç noktasının barındırıldığı sunucunun etki alanı adı veya IP adresi.

İstek gövdesi

Daha önce belirtildiği gibi, istekte bulunduğunuz işleme ve parametre gereksinimlerine bağlı olarak istek iletisi gövdesi isteğe bağlıdır. Gerekirse, istediğiniz hizmetin API belirtimi de kodlamayı ve biçimi belirtir.

İstek gövdesi üst bilgiden boş bir satırla ayrılır ve üst bilgi alanına uygun Content-Type olarak biçimlendirilir. "application/json" biçimli gövde örneği aşağıdaki gibi görünür:

{
  "<name>": "<value>"
}

İsteği gönderme

Hizmetin istek URI'sine sahip olduğunuza ve ilgili istek iletisi üst bilgisini ve gövdesini oluşturduğunuza göre, isteği REST hizmet uç noktasına göndermeye hazırsınız demektir.

Örneğin, aşağıdakine benzer istek üst bilgisi alanlarını kullanarak bir Azure Resource Manager sağlayıcısı için HTTPS GET istek yöntemi gönderebilirsiniz (istek gövdesinin boş olduğunu unutmayın):

GET /subscriptions?api-version=2014-04-01-preview HTTP/1.1
Authorization: Bearer <bearer-token>
Host: management.azure.com

<no body>

Ayrıca aşağıdaki örneğe benzer istek üst bilgisi ve gövde alanlarını kullanarak Azure Resource Manager sağlayıcısı için HTTPS PUT istek yöntemi gönderebilirsiniz:

PUT /subscriptions/.../resourcegroups/ExampleResourceGroup?api-version=2016-02-01  HTTP/1.1
Authorization: Bearer <bearer-token>
Content-Length: 29
Content-Type: application/json
Host: management.azure.com

{
  "location": "West US"
}

İsteği yaptıktan sonra yanıt iletisi üst bilgisi ve isteğe bağlı gövde döndürülür.

Yanıt iletisini işleme

Süreç, beş bileşenin son ikisiyle sona erer.

Yanıtı işlemek için yanıt üst bilgisini ve isteğe bağlı olarak yanıt gövdesini ayrıştırın (isteğe bağlı olarak). Önceki bölümde sağlanan HTTPS GET örneğinde, bir kullanıcının abonelik listesini almak için /subscriptions uç noktasını kullandınız. Yanıtın başarılı olduğunu varsayarsak, aşağıdaki örneğe benzer yanıt üst bilgisi alanlarını almanız gerekir:

HTTP/1.1 200 OK
Content-Length: 303
Content-Type: application/json;

Ayrıca, Aşağıdakine benzer şekilde JSON biçiminde kodlanmış Azure aboneliklerinin ve bunların tek tek özelliklerinin listesini içeren bir yanıt gövdesi almalısınız:

{
    "value":[
        {
        "id":"/subscriptions/...",
        "subscriptionId":"...",
        "displayName":"My Azure Subscription",
        "state":"Enabled",

"subscriptionPolicies":{
            "locationPlacementId":"Public_2015-09-01",
            "quotaId":"MSDN_2014-05-01",
            "spendingLimit":"On"}
        }
    ]
}

Benzer şekilde, HTTPS PUT örneği için aşağıdakine benzer bir yanıt üst bilgisi almanız ve "ExampleResourceGroup" ekleme put işleminizin başarılı olduğunu onaylamanız gerekir:

HTTP/1.1 200 OK
Content-Length: 193
Content-Type: application/json;

Ayrıca yeni eklenen kaynak grubunuzun içeriğini JSON biçiminde kodlanmış olarak onaylayan bir yanıt gövdesi almanız gerekir; örneğin:

{
    "id":"/subscriptions/.../resourceGroups/ExampleResourceGroup",
    "name":"ExampleResourceGroup",
    "location":"westus",
    "properties":
        {
        "provisioningState":"Succeeded"
        }
}

İstekte olduğu gibi, çoğu programlama dili ve çerçeve yanıt iletisini işlemeyi kolaylaştırır. Genellikle bu bilgileri isteğin ardından uygulamanıza döndürerek bunu türü/yapılandırılmış biçimde işlemenizi sağlar. Temel olarak, yanıt üst bilgisindeki HTTP durum kodunu onaylamak ve yanıt gövdesini API belirtimine (veya Content-Type ve Content-Length yanıt üst bilgisi alanlarına) göre ayrıştırmak istiyorsunuz.

Zaman uyumsuz işlemler, azaltma ve sayfalama

Bu makalede açıklanan Oluşturma/Gönderme/İşlem-Yanıt düzeni zaman uyumludur ve tüm REST iletileri için geçerlidir. Ancak bazı hizmetler, zaman uyumsuz isteği izlemek veya tamamlamak için yanıt üst bilgilerinin ek işlenmesini gerektiren zaman uyumsuz bir düzeni de destekler. Daha fazla bilgi için bkz. Zaman uyumsuz Azure işlemlerini izleme.

Resource Manager, bir uygulamanın çok fazla istek göndermesini önlemek için saat başına okuma ve yazma isteği sayısına bir sınır uygular. Uygulamanız bu sınırları aşarsa istekler kısıtlanmış olur. Yanıt üst bilgisi, kapsamınız için kalan istek sayısını içerir. Daha fazla bilgi için bkz. Resource Manager isteklerini kısıtlama.

Bazı liste işlemleri yanıt gövdesinde adlı nextLink bir özellik döndürür. Sonuçlar tek bir yanıtta döndürülemeyecek kadar büyük olduğunda bu özelliği görürsünüz. Genellikle, liste işlemi 1.000'den fazla öğe döndürdüğünde yanıt nextLink özelliğini içerir. sonuçlarda nextLink olmadığında, döndürülen sonuçlar tamamlanmış olur. nextLink bir URL içerdiğinde, döndürülen sonuçlar toplam sonuç kümesinin yalnızca bir parçasıdır.

Yanıt şu biçimdedir:

{
  "value": [
    <returned-items>
  ],
  "nextLink": "https://management.azure.com/{operation}?api-version={version}&%24skiptoken={token}"
}

Sonuçların sonraki sayfasını almak için nextLink özelliğindeki URL'ye bir GET isteği gönderin. URL, sonuçlarda nerede olduğunuzu belirten bir devamlılık belirteci içerir. Döndürülen sonuçlarda artık url içermeyene kadar nextLink URL'sine istek göndermeye devam edin.

Azure API'lerinin dayanıklılığı

Azure REST API'leri dayanıklılık ve sürekli kullanılabilirlik için tasarlanmıştır. REST API'deki denetim düzlemi işlemleri (management.azure.com gönderilen istekler) şunlardır:

  • Bölgeler arasında dağıtılır. Bazı hizmetler bölgeseldir.

  • Birden çok Kullanılabilirlik Alanları olan konumlarda Kullanılabilirlik Alanları (bölgelerin yanı sıra) arasında dağıtılır.

  • Tek bir mantıksal veri merkezine bağımlı değildir.

  • Bakım etkinlikleri için hiçbir zaman indirilmedi.

İşte bu kadar. Microsoft Entra uygulamanızı kaydettikten ve erişim belirteci almak ve HTTP isteklerini işlemek için modüler bir teknik elde ettikten sonra, yeni REST API'lerinden yararlanmak için kodunuzu çoğaltmak oldukça kolaydır. Uygulama kaydı ve Microsoft Entra programlama modeli hakkında daha fazla bilgi için Microsoft kimlik platformu belgelerine bakın.

HTTP isteklerini/yanıtlarını test etme hakkında bilgi için bkz:

  • Fiddler. Fiddler, REST isteklerinizi keserek HTTP istek/yanıt iletilerini tanılamayı kolaylaştıran ücretsiz bir web tabanlı hata ayıklama ara sunucusudur.
  • JWT.ms; bu sayede talepleri taşıyıcı belirtecinize hızla ve kolay bir şekilde atarak içeriklerini doğrulayabilirsiniz.