Başlangıçtaki ikinci öğe artık aynı yerde olmayabilir
Ajan dört öğeli bir listeden B ve C’yi çıkarmak istiyor. Başlangıçta bu öğeler 1 ve 2 indislerinde. Ajan önce 1’i, sonra 2’yi siliyor; sonuçta B ve D kayboluyor. İndisler doğru okunmuş, fakat ikinci işlemin hangi diziye uygulandığı yanlış varsayılmış. Bir silme işlemi sonraki öğelerin konumunu değiştirir.
JSON Patch standardında işlemler sırayla uygulanır; her işlem bir öncekinin ürettiği belge üzerinde çalışır. Diziden bir öğe kaldırıldığında daha yüksek indisli öğeler bir konum sola kayar. Bu yazıda aynı başlangıç verisi üzerinde yanlış sıra, azalan sıra ve değer kontrolü içeren bir yama hazırlayacağız.Kaynak: IETF — RFC 6902: JSON Patch
Veri ve bütün çıktılar sentetiktir. Gerçek bir dış sisteme güncelleme gönderilmiyor. Çalışmanın çıktısı, gözden geçirilebilir bir yama taslağı ile her adımın ara durumudur. Bir HTTP isteğinin işlem bütünlüğü, yetkilendirmesi ve eşzamanlılık davranışı ayrıca doğrulanması gereken uygulama özellikleridir.
Niyet ile konumu ayrı yazın
| İndis | Değer | Niyet |
|---|---|---|
| 0 | A | Kalsın |
| 1 | B | Silinsin |
| 2 | C | Silinsin |
| 3 | D | Kalsın |
Belgemiz {"items":["A","B","C","D"]} biçimindedir. Yama yolları /items/1 ve /items/2 olarak yazılır. Buradaki indisler sıfırdan başlar. B ve C harfleri bu örnekte tekil öğe kimliğini temsil eder; gerçek listede aynı görünen metinlerin farklı kayıtlar olabileceğini unutmayın. Silme niyetini yalnız konumla tarif etmek, liste değiştiğinde yanlış öğeyi hedefleyebilir.
Başlangıç: [A,B,C,D] remove /items/1 → [A,C,D] (B silindi) remove /items/2 → [A,C] (D silindi) İstenen sonuç [A,D] idi; C kaldı, D yanlışlıkla çıktı.
İkinci işlem başarısız olmak zorunda değildir. İlk silmeden sonra indis 2 hâlâ vardır; artık D’yi gösterir. Bu yüzden yalnız “yama hata vermedi” kontrolü yanlış silmeyi yakalayamaz. İşlem sonunda hangi kimliklerin kaldığını ve hangilerinin çıktığını niyet listesiyle karşılaştırmak gerekir. Geçerli yol, doğru hedef kimliği demek değildir.
Yüksek indisi önce silin
Başlangıç dizisindeki B ve C hedefleri değişmiyorsa önce daha yüksek indis olan 2’yi, ardından 1’i silin. İlk işlem C’yi çıkarıp [A,B,D] bırakır. B’nin indisi hâlâ 1 olduğundan ikinci işlem doğru hedefi çıkarır. Sonuç [A,D] olur. Bu yöntem aynı başlangıç dizisinden seçilmiş birden çok silme için yararlı bir düzenleme kuralıdır.
| Adım | İşlem | Çıkan değer | Kalan dizi |
|---|---|---|---|
| 1 | remove /items/2 | C | [A,B,D] |
| 2 | remove /items/1 | B | [A,D] |
Bu basit kuralı ekleme, taşıma ve silmenin karıştığı her yamaya otomatik uygulamayın. Başka işlemler konumları farklı biçimde değiştirebilir; bütün işlem dizisini ara belge üzerinde değerlendirmek gerekir. Aynı şekilde başlangıç listesi kullanıcı gözden geçirdikten sonra değişmişse azalan sıra tek başına eski niyeti korumaz.
Bu özel örnekte /items/1 yolunu iki kez silmek de B ve sonra C’yi çıkarır. Ancak bunun neden doğru olduğu ikinci işlemin yeni dizideki C’yi hedeflemesidir. “Aynı indis iki kez silinemez” gibi bir kural çıkarmayın. Önemli olan her adımın hedefi ve ara durumudur; farklı doğru yamalar aynı sonuca ulaşabilir.
Silmeden önce beklenen öğeyi test edin
[
{"op":"test","path":"/items","value":["A","B","C","D"]},
{"op":"test","path":"/items/2","value":"C"},
{"op":"remove","path":"/items/2"},
{"op":"test","path":"/items/1","value":"B"},
{"op":"remove","path":"/items/1"}
]İlk test bütün başlangıç dizisinin beklenen durumda olduğunu denetler. Sonraki testler silinecek konumun beklenen değeri taşıdığını gösterir. RFC 6902’de test işlemi, belirtilen değerin hedefteki değerle eşit olmasını gerektirir; başarısız işlem durumunda yamanın uygulanması sonlandırılır. Kullandığınız kitaplığın hata bildirimini ve belgeyi hangi aşamada değiştirdiğini ayrıca kontrol edin.Kaynak: IETF — RFC 6902: JSON Patch
Yerel bir eğitim uygulamasında güvenli inceleme için önce belgenin kopyasına bütün yamayı uygulayıp ancak tüm testler başarılıysa yeni kopyayı kabul edebilirsiniz. Bu, örneğin seçtiği uygulama tasarımıdır. Her JSON Patch kitaplığının bellekte yaptığı değişiklikleri otomatik geri aldığı varsayılmaz. Gerçek HTTP güncellemesinde sunucunun işlem bütünlüğü ve sürüm koşulları da değerlendirilmelidir.
Başlangıç dizisi [X,A,B,C,D] haline gelmişse ilk test başarısız olmalıdır. Eski indisleri yeni listeye uygulamak yerine güncel belge üzerinde niyeti tekrar çözümleyin. Sunucunun desteklediği sürüm koşulu varsa, gözden geçirilen sürümün hâlâ geçerli olduğunu işlem anında doğrulamak da gerekir. Yalnız istemcide önceden test yapmak eşzamanlı değişikliği engellemez.
Yamayı ara durumlarıyla isteyin
Belge {"items":["A","B","C","D"]}. Niyet B ve C kimliklerini silmek, A ve D’yi korumak. Önce remove /items/1 ve sonra /items/2 dizisinin neden yanlış olduğunu her ara durumla göster. Azalan indisle doğru JSON Patch yaz. Başlangıç dizisi ve silinecek değerler için test işlemleri ekle. Yamayı inceleme kopyasında değerlendir; test başarısızsa kabul edilen belgeyi değiştirme. Üretim kitaplığının otomatik geri alma davranışını varsayma.Yanıtı incelerken üç kümeyi karşılaştırın: başlangıç kimlikleri, istenen silmeler ve sonuç kimlikleri. Bu örnekte sonuç A ve D’yi birer kez içermeli, B ve C’yi içermemelidir. Ajan doğru son diziyi yazıp yanlış işlemler üretebilir; bu yüzden yalnız açıklama metnini okumak yerine yamanın adımlarını gerçekten yürütün.
İşlemlerin sırası JSON dizisindeki sıradır. Nesne alanlarının görsel sırasıyla veya araç ekranındaki ayrı kartların sırasıyla karıştırmayın. Yama başka bir araca aktarılıyorsa işlem dizisinin sırası korunmalı; araç paralel uygulama yapmamalıdır. Bu uygulamada ikinci adımın anlamı açıkça ilk adımın sonucuna bağlıdır.
B ve D’yi beş öğeli listeden çıkarın
Yeni başlangıç [A,B,C,D,E] olsun. Niyet B ve D’yi silmektir. Başlangıç indislerini küçükten büyüğe silen yanlış yamayı ve büyükten küçüğe silen doğru yamayı ayrı yürütün. Sonra başlangıca X eklendiğinde eski test korumalı yamanın nasıl davranması gerektiğini açıklayın.
Yanlış sıra 1 sonra 3: [A,C,D,E] ardından [A,C,D]; B ve E silinir. Doğru sıra 3 sonra 1: [A,B,C,E] ardından [A,C,E]; B ve D silinir. Baştaki X başlangıç belgesini değiştirir; eski tam dizi testi başarısız olur ve kabul edilen belge korunmalıdır.
Kendi ajan akışınızda silme taslağını hedef kimlikler, başlangıç sürümü ve ara durumlarla birlikte gözden geçirin. Sonuç kümesini niyetle karşılaştıran bu küçük kontrol, sözdizimi geçerli olduğu halde yanlış öğeyi değiştiren işlemleri görünür kılar.
Kaynaklar ve doğrulama
- IETF — RFC 6902: JSON Patch
İşlemlerin sırayla ara belgeye uygulanması ve dizi elemanı silinince sonraki indislerin sola kayması.
Erişim ve kontrol:
AI Ajanları ve İş Akışı Otomasyonu
Güncelleme yapan bir ajan geliştiriyorsanız AI Ajanları ve Otomasyon eğitiminde taslak işlemleri, önkoşulları ve sonuç kimliklerini birlikte inceleyebilirsiniz.
- Kuruma özel planlanır