27 Aralık 2021 Pazartesi

POST isteklerini Koşullu Yapma

PUT veya DELETE den farklı olarak yapılan bir kaynağa gönderilen POST isteğinin sonucu, herhangi bir istek URI deki kaynağa yapılan değişiklikler sunucuda yeni bir kaynak oluşturabilir. Yanıt kodu 201 veya sonucu farklı bir URI ile tanımlanayabilirsiniz. Yanıt kodu 303. Bu durumda müşterinin bir temsili olmayacak ve şartlı yerel olarak depolanan üstbilgiler dahil. Bu tür POST isteklerini yapmak için bağlantıların nasıl kullanılacağını gösterir. POST  istekleri koşullu veya yanıtsız hale getirmek için bu tarifi uygulayabiliriz. 

Müşteri tarafından sunulması için POST u sunucunun yinelemeleri algılayabileceği ve önleyebileceği şekilde uygulamak istiyoruz.

İstemcilerin her POST isteği için bir bağlantı aracılığıyla sunucu tarafından sağlanan tek seferlik bir URI oluşturmak için  bir jeton içerir. POST isteğinin yalnızca bir kullanım için geçerli olan sunucu. Kullanılan tüm jetonları bir sunucu işlem günlüğünde saklanır. 

İstemci bir POST isteği gönderdiğinde jetonun işlemde mevcut olup olmadığını doğrulayın. Varsa yanıt kodu 403 döndürün. Neden bodyde olduğunu açıklayın. Eğer mevcut değilse dönme isteğine 201 oluşturun yada 303 ile bağlı olarak işlemi sonuçlandırın. Ayrıca belirteci işlem günlüğünde saklayın.

Sunucunun belirli bir miktar transfer etmesi gereken banka havalesi uygulaması olduğunu düşünelim.  Bir hesaptan diğer bir hesaba para aktarımı. Sunucu bir denetleyici kaynağı kullanarak bu transferi uygulayın.

# Request

POST /transfersİki banka hesabının kaynağına müşteri mevcut durum olduğunu düşündüğü şeye dayanarak bir POST isteği gönderir. 

Host: example.org

Content-Type: application/xml;charset=UTF-8

<transfer>

   <source>urn:example:org:account:1</source>

<target>urn:example:org:account:2</target>

<currency>USD</currency>
   <amount>100.00</amount>
   <note>Testing transfer</note>
</transfer>

# Response
HTTP/1.1 201 Created> Sunucu istemcinin isteğini şuanki duruma dayanıp dayanmadığını hesap kaynalarına göre doğurlayamıyor.

Content-Type: application/xml;charset=UTF-8
Location: http://www.example.org/transactions/1
Content-Location: http://www.example.org/transactions/1

<transfer xmlns:atom="http://www.w3.org/2005/Atom">
   <source>urn:example:org:account:1</source>
   <target>urn:example:org:account:2</target>
   <atom:link href="http://www.example.org/transactions/1" rel="self"/>
   <currency>USD</currency>
   <amount>100.00</amount>
   <note>Testing transfer</note>
</transfer>

Bu örnekte; http://www.example.org/trans tarafından tanımlanan kaynak ters bir denetçi kaynağıdır. Bu örnekteki POST isteğinin sonucu şu şekildedir. iki hesap kaynağının değiştirilmesi ve  yeni bir kaynağın oluşturulaması. Bunu yapmak için istek koşulu olarak; sunucu değerin bir işlev olarak belirteç kullanması gerekir. iki hesap kaynağının mevcut durumu bulabilmek için.  Sunucu aşağıdaki yaratılan URI kullanabilir.

http://www.example.org/transfers;t=e6e3c89d4dfe7f3a818734a6237ccfc5

Değiştirilmesi istenen iki kaynaktan; http://www.example.org/transfers  aksine bu URI bir işlev olarak bir belirteç içerir.  İstemci bir aktarım talebinde bulunmak için URI kullanabilir. Sunucu, URI deki belirtecin hala şuanki duruma karşılıl geldiğini doğrulayabilir. Bir hesap aktarımı oluşturmaya devam etmeden önce hesap kaynaklarını doğrulamak gerekir.

# Request
POST /transfer;t=e6e3c89d4dfe7f3a818734a6237ccfc5 HTTP/1.1 > İstemci geçerli veriyi temel alan bir URI ile koşullu bir POST isteği gönderir. Ancak bu gönderim sadece iki banka hesabı kaynağı olduğu sürece.

Host: example.org
Content-Type: application/xml;charset=UTF-8

<transfer>
   <source>urn:example:org:account:1</source>
   <target>urn:example:org:account:2</target>
   <currency>USD</currency>
   <amount>100.00</amount>
   <note>Testing transfer</note>

</transfer>

# Response

HTTP/1.1 201 Created > Sunucu, istemcinin isteğinin şuanki durumuna dayanıp dayanmadığının kontrolünü yapması ve hesap kaynaklarınında kontrolünün yapması sonrasında.

Content-Type: application/xml;charset=UTF-8
Location: http://www.example.org/transactions/1
Content-Location: http://www.example.org/transactions/1
<transfer xmlns:atom="http://www.w3.org/2005/Atom">

   <source>urn:example:org:account:1</source>
   <target>urn:example:org:account:2</target>
   <atom:link href="http://www.example.org/transactions/1" rel="self"/>
   <currency>USD</currency>
   <amount>100.00</amount>
   <note>Testing transfer</note>
</transfer>



Sunucudaki, jetonun sunucunun işlem günlüğü.

# Request
POST /transfer;t=e6e3c89d4dfe7f3a818734a6237ccfc5 HTTP/1.1 > İstemci koşullu bir POST isteği gönderir.
Host: example.org
Content-Type: application/xml;charset=UTF-8

<transfer>
   <source>urn:example:org:account:1</source>
   <target>urn:example:org:account:2</target>
   <currency>USD</currency>
   <amount>100.00</amount>
   <note>Testing transfer</note>

</transfer>

# Response
HTTP/1.1 403 Forbidden > Sunucu bir çakışma algıdı.
Content-Type: application/xml;charset=UTF-8
Date: Sat, 17 Oct 2019 20:16:18 GMT

<error xmlns:atom="http://www.w3.org/2005/Atom">
   <message xml:lang="en">Transfer already created.</message>
</error>


Bu sefer, sunucu, belirtecin önceden kaydedilmiş olup olmadığını görmek için işlem günlüğünü kontrol eder. Kullanılmış kopya oluşturmak yerine 403 döndürür. Bu teknikte POST tam olarak bir  kez çağrıldı.

12 Aralık 2021 Pazar

Koşullu PUT ve DELETE talepleri Nasıl Gönderilir.

 

İstemci PUT kullanarak yeni bir kaynak oluşturduğunda veya sunucu If Kaynağa yapılan önceki bir GET veya PUT isteğinden beri Değiştirilmiş ve/veya ETAG başlıkları her zamanki gibi PUT isteklerinde bulunur.

İstemcinin önceki bir istekten beri Değiştirildiği Tarih ve/veya ETAG başlıkları varsa kaynak PUT , DELETE istekleri yaparken aşağıdaki başlıkları bu talepli koşullarda eklenir.

* Last-Modified başlığıyla aynı değere sahip bir If-Unmodified-Since başlığı. Sunucunun isteği işlenmesi gerektiğini belirtmek için yanlızca suncuda bu başlıkta belirtilen zamandan beri kaynakta değişiklik yapılmalıdır.

*ETAG başlığıyla aynı değere sahip bir If-Match başlığı sunucu isteği yalnızca ve ancak sağlanan üstbilgi değeri eşlenirse işlemelidir. Mevcut ETAG değeri için belirtilmelidir.

Sunucu 412 (Ön Koşul Başarısız) durum kodunu döndürürse koşulsuz bir yeni Last-Modified ve ETAG başlıklarını almak için GET isteği kaynağının güncellenmesi veya silinmesi kararı yeni temsile göre hala geçerlidir. Sonra bu başlıklarla PUT veya DELETE isteğini tekrar etmeniz gerekir.

Koşullu bir PUT isteğinde bulunan bir istemciye örnek;

# Request
PUT /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
If-Unmodified-Since: Sun, 09 Aug 2019 00:56:14 GMT
If-Match: "3f4a74db207d0447d46710a64971e777"
.....
# Response
HTTP/1.1 200 OK
Date: Sun, 16 Aug 2019 01:00:23 GMT
Content-Location: http://www.example.org/reviews/notes_from_underground
Last-Modified: Sun, 16 Aug 2019 01:00:23 GMT
E-Tag: "5bbae963eb30e03cf1fd218a9dc92a5b"
Content-Type: application/xml; charset=UTF-8
.....

Bu istekte, If-Unmodigied-Since değeri Last-Modified başlığının değeridir. Müşteri önceki bir talep sırasında elde ettiği, benzer şekilde değer If-Match başlığı , ETAG başlığının değeridir. 
Müşteri zaten sahip değilse temsilinin kopyası için veya sunucu yanıt kodunu döndürürse bu başlıklar 412 almak için yeni bir koşulsuz istek GET gönderilmesi gerekir.

# Unconditional GET request
GET /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
Cache-Control: no-cache
Pragma: no-cache
# Response
HTTP/1.1 200 OK
Content-Type: application/xml;charset-UTF-8
Date: Sun, 16 Aug 2019 01:00:23 GMT
Last-Modified: Sun, 09 Aug 2019 00:55:46 GMT
ETag: "3f4a74db207d0447d46710a64971e777"

HEAD talebinde bulunarak bu başlıkları elde etmek yeterli değildir. İstemciler bu başlıklar kaynağın mevcut durumuna karşılık gelir. Başlıkları bir HEAD isteği araclığıyla tek başına almak, müşterinin bunu bilmesine yardımcı olmayacaktır. Kaynağın mevcut durumu, body nin onunla birlikte alınması gerekir. Üstbilgiler dahil.


İstemci DELETE istekleri için aynı süreci izlemelidir. 412 herhangi bir istek istemcinin güncelleme veya silme kararı verdiğini gösterir.


# Conditional request
PUT /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
If-Unmodified-Since: Sun, 09 Aug 2019 00:56:14 GMT
If-Match: "3f4a74db207d0447d46710a64971e777"
# Response
HTTP/1.1 412 Precondition Failed

Content-Type: application/xml;charset=UTF-8
<error>
   <message>The review you are trying to update has changed.</message>
   <description>You are trying to update a resource based on stale information.
   Get a new copy of this review, resolve any differences, and retry.</description>
</error>

9 Aralık 2021 Perşembe

Müşteriden Koşulsuz GET Talepleri Nasıl Yapılır

  HTTP 1.1 istemcilerin sona erme önbelleğini değiştirmesine ve yeni temsiller istemesine izin verir. Bu tarif bir kaynak aldıktan sonra bir kayanağın yeni bir temsilini almak için kullanabilirsiniz. 412 (Ön Koşul Başarısız ) veya en yenisini almak için başarılı bir PUT veya PATCH den sonra  bile oluşan temsildir. 

GET isteğinde; Cache-Control : non-cache ve Pragma: non-cache üst bilgilerini ekleyin.

İstemcinin bir kaynağı güncellemek için koşullu bir PUT isteğinde bulunduğunu varsayalım.  Katmanlı koşullar eşleşmiyor ve sunucu 412 yi döndürüyorsa.

# Process this request if and only if the included conditional tags match

PUT /reviews/notes_from_underground HTTP/1.1

Host: www.example.org

If-Unmodified-Since: Sun, 09 Aug 2019 00:56:14 GMT

If-Match: "3f4a74db207d0447d46710a64971e777"

...

# Response

HTTP/1.1 412 Precondition Failed

Content-Length: 0


Müşteri artık yeni bir temsil almak için koşulsuz  kaynağından bir GET talebinde bulunabilir. 

# Request
GET /status HTTP/1.1
Cache-Control: no-cache> Önbellek kontrolü: önbelleksiz ve Pragma önbelleksiz üstbilgiler, istemci koşullu isteklerini ortadan kaldırır.
Pragma: no-cache

# Response
HTTP/1.1 200 OK
Date: Sun, 09 Aug 2019 05:20:10 GMT
Last-Modified: Sun, 09 Aug 2019 05:20:10 GMT > Sunucu uygulanabilir değiştirilmiş. Last-ETAG
ETag: "a3d3005f4a1632c88e8889af985e6294"
Expires: Sun, 09 Aug 2019 15:56:14 GMT
Cache-Control: max-age=36000,public
Content-Type: application/xml; charset=UTF-8
...


İstekleri non-cache yönergesi herhangi bir ara önbellekten önbelleğe sunmamasını ister. Temsil eder ve isteği kaynak sunucuya iletir.

Bazı önbelleklerin önbellek yok yönergesi sayacak şekilde yapılandırabildiğini unutmayalım. Böyle durumlarda önbellekler bir UYARI başlığı döndürebilir. 

# Request
GET /status HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
# Response
Date: Sun, 09 Aug 2019 00:56:14 GMT
Last-Modified: Sun, 09 Aug 2019 00:56:14 GMT
Expires: Sun, 09 Aug 2019 10:56:14 GMT
Cache-Control: max-age=36000,public
Content-Type: application/xml; charset=UTF-8
Age: 1021
Warning: 110



Warning başlığının değeri bir tamsayı kodudur ve bu örnekte şunu belirtir. Yanıt eski, bu başlıkla ilgili daha fazla ayrıntı için HTTP 1.1 e göz atmanız gerekir. 

NOT:
Gerekmedikçe koşulsuz GET talepleri yapmayın. Koşulsuz istekler performansı düşürür ve gecikmeyi artırır.