Açık, kullanıcı dostu mesajlar için API hata sözleşmesi kalıpları

Neden belirsiz API hataları gerçek kullanıcı sorunları yaratır

Belirsiz bir API hatası sadece teknik bir rahatsızlık değildir. Üründe birinin takıldığı, ne yapacağını tahmin ettiği ve çoğunlukla vazgeçtiği kırılmış bir andır. O tek "Bir şeyler yanlış gitti" mesajı daha fazla destek talebi, müşteri kaybı ve tam olarak çözülemeyen hatalar demektir.

Yaygın bir desen şöyle görünür: kullanıcı bir formu kaydetmeyi dener, arayüz genel bir bildirim gösterir ve arka uç loglarında gerçek neden ("unique constraint violation on email") görünür. Kullanıcı neyi değiştireceğini bilmez. Destek yardımcı olamaz çünkü loglarda aranacak güvenilir bir kod yoktur. Aynı sorun farklı ekran görüntüleri ve ifadelerle raporlanır ve bunları gruplamanın temiz bir yolu yoktur.

Geliştiricinin ihtiyaçları ile kullanıcının ihtiyaçları aynı şey değildir. Mühendisler hangi alanın, hangi servisin, hangi zaman aşımının olduğunu gösteren kesin hat bilgisine ihtiyaç duyar. Kullanıcılar ise şu gibi net bir sonraki adım ister: "Bu e-posta zaten kullanılıyor. Giriş yapmayı deneyin veya başka bir e-posta kullanın." Bu ikisini karıştırmak genellikle ya iç ayrıntıların güvensiz ifşasına (internal'lerin sızması) ya da işe yaramayan mesajlara (her şeyi gizleme) yol açar.

İşte API hata sözleşmesi bunun için vardır. Amaç "daha fazla hata" değil. Amaç, aşağıdakileri sağlayan tek, tutarlı bir yapı:

• istemcilerin uç noktalar arasında hataları güvenilir şekilde yorumlayabilmesi
• kullanıcıların güvenli, yalın dille yazılmış ve toparlanmalarına yardımcı mesajlar görmesi
• destek ve QA'nın sabit bir kodla tam sorunu belirleyebilmesi
• mühendislerin hassas ayrıntıları ifşa etmeden tanılara erişebilmesi

Tutarlılık her şeydir. Bir uç nokta error: "Invalid" dönerken başka bir uç nokta message: "Bad request" döndürüyorsa, arayüz kullanıcıya rehberlik edemez ve ekibiniz ne olduğunu ölçemez. Açık bir sözleşme hataları öngörülebilir, aranabilir ve düzeltmesi daha kolay hale getirir; alttaki nedenler değişse bile.

Tutarlı bir hata sözleşmesi pratikte ne demektir

API hata sözleşmesi bir sözdür: bir şey yanlış gittiğinde API'niz hangi uç nokta başarısız olursa olsun tanıdık bir biçimde, öngörülebilir alanlar ve kodlarla yanıt verir.

Bu bir hata ayıklama dökümü değildir ve logların yerine geçmez. Sözleşme, istemci uygulamaların güvenle dayanabileceği şeydir. Stack trace'ler, SQL ayrıntıları ve hassas bilgiler loglarda tutulmalıdır.

Pratikte sağlam bir sözleşme birkaç şeyi sabit tutar: uç noktalar arasında yanıt şekli (hem 4xx hem 5xx için), anlamı değişmeyen makine-okunur hata kodları ve güvenli kullanıcıya yönelik bir mesaj. Ayrıca destek için bir istek/izleme tanımlayıcısı içerir ve kullanıcının tekrar denemesi veya bir alanı düzeltmesi gibi basit UI ipuçlarını barındırabilir.

Tutarlılık ancak nerede uygulandığına karar verdiğinizde işler. Takımlar genellikle tek bir uygulama noktasından başlar ve sonra genişletir: hataları normalize eden bir API gateway, yakalanmamış hataları saran bir middleware, aynı hata nesnesini oluşturan ortak bir kütüphane veya servis başına framework seviyesinde bir istisna işleyicisi.

Temel beklenti basittir: her uç nokta ya bir başarı şekli ya da her hata modu için hata sözleşmesini döndürür. Bu, doğrulama hataları, kimlik doğrulama başarısızlıkları, oran sınırlamaları, zaman aşımı ve üst sistem arızalarını içerir.

Ölçeklenen basit bir hata yanıt şekli

İyi bir API hata sözleşmesi küçük, öngörülebilir ve hem insanlar hem yazılımlar için faydalı kalır. Bir istemci her zaman aynı alanları bulabildiğinde, destek tahmin yürütmeyi bırakır ve arayüz daha net rehberlik sağlar.

Çoğu ürün için işe yarayan minimal bir JSON şekli şöyle olabilir:

{
  \"status\": 400,
  \"code\": \"AUTH.INVALID_EMAIL\",
  \"message\": \"Enter a valid email address.\",
  \"details\": {
    \"fields\": {
      \"email\": \"invalid_email\"
    },
    \"action\": \"fix_input\",
    \"retryable\": false
  },
  \"trace_id\": \"01HZYX8K9Q2...\"
}

Sözleşmeyi sabit tutmak için her parçayı ayrı bir taahhüt gibi ele alın:

• status HTTP davranışı ve geniş kategoriler içindir.
• code sabit, makine-okunur tanımlayıcıdır (API hata sözleşmenizin çekirdeği).
• message güvenli bir UI metnidir (daha sonra yerelleştirebileceğiniz bir şey).
• details yapılandırılmış ipuçlarını tutar: alan düzeyinde sorunlar, bir sonraki yapılacak ve tekrar denenip denemeyeceği.
• trace_id destek ekibinin sunucu tarafı hatasını hassas bilgiler sızdırmadan bulmasını sağlar.

Kullanıcıya gösterilen içeriği dahili hata ayıklama bilgisinden ayrı tutun. Ek tanılara ihtiyaç varsa, bunları trace_id ile anahtarlanmış şekilde sunucuda loglayın (yanıtta değil). Bu, hassas verilerin sızmasını engellerken sorunların araştırılmasını kolaylaştırır.

Alan hataları için details.fields basit bir desendir: anahtarlar giriş isimleriyle eşleşir, değerler invalid_email veya too_short gibi kısa nedenler içerir. Yalnızca yardımcı olduğunda rehberlik ekleyin. Zaman aşamaları için action: "retry_later" yeterlidir. Geçici kesintiler için retryable: true istemcilerin bir yeniden deneme düğümü gösterip göstermeyeceğine karar vermesine yardımcı olur.

Uygulamaya geçmeden önce bir not: bazı takımlar hataları bir error nesnesinde sarar (örneğin { \"error\": { ... } }) bazıları ise alanları üst düzeyde tutar. Hangi yaklaşımı seçerseniz seçin, her yerde aynı zarfa sahip olmak ve bunu tutarlı uygulamak önemlidir.

İstemcileri bozmayan sabit hata kodları: kalıplar

Sabit hata kodları bir API hata sözleşmesinin bel kemiğidir. Metni değiştirdiğinizde, alanlar eklediğinizde veya UI'ı geliştirdiğinizde uygulamalar, panolar ve destek ekipleri problemi tanıyabilir.

Pratik bir adlandırma kuralı şudur:

DOMAIN.ACTION.REASON

Örnekler: AUTH.LOGIN.INVALID_PASSWORD, BILLING.PAYMENT.CARD_DECLINED, PROFILE.UPDATE.EMAIL_TAKEN. Domainleri küçük ve tanıdık tutun (AUTH, BILLING, FILES). Eylem fiilleri açık okuyacak şekilde olsun (CREATE, UPDATE, PAY).

Kodlara bir kez kamuya açık olduklarında anlamlarını değiştirmeyin. Kullanıcıya gösterilen metin zaman içinde iyileşebilir (daha iyi ton, daha net adımlar, yeni diller), ancak kod aynı kalmalıdır, böylece istemciler bozulmaz ve analizler temiz kalır.

Ayrıca hangi kodların halka açık, hangilerinin sadece dahili olduğunu kararlaştırmak faydalıdır. Basit bir kural: genel kodlar gösterilmeye uygun, sabit ve belgelenmiş olmalıdır; dahili kodlar debug için loglarda kalır (veritabanı adları, satıcı ayrıntıları, stack bilgisi). Bir genel kod birçok dahili nedene eşlenebilir, özellikle bir bağımlılık birden fazla şekilde başarısız olabiliyorsa.

Kademeli olarak bir kodu devre dışı bırakmanız gerekirse bunu sıkıcı hale getirin. Bir kodu değiştirmek zorundaysanız, anlamını yeniden kullanmayın. Yeni bir kod tanımlayın ve eskisini kullanımdan kaldırın. İstemcilere her iki kodun görünebileceği bir çakışma penceresi verin. deprecated_by gibi bir alan ekliyorsanız, yeni koda işaret edin (URL değil).

Örneğin, BILLING.PAYMENT.CARD_DECLINED kodunu koruyun; arayüz kopyasını geliştirip "Başka bir kart deneyin" ile "Banka ile görüşün" arasında ayrım yapsanız bile kod sabit kalır.

Tutarlılığı kaybetmeden yerelleştirilmiş mesajlar

API full cümleleri döndürüp istemcilerin bunları mantık için kullanması yerelleştirmeyi karmaşıklaştırır. Daha iyi yaklaşım, sözleşmeyi sabit tutmak ve son kilometre metnini çeviride yönetmektir. Böylece aynı hata kullanıcının dili, cihazı veya uygulama sürümünden bağımsız olarak aynı anlama gelir.

Önce çevirilerin nerede tutulacağına karar verin. Web, mobil ve destek araçları arasında tek bir kaynak isterseniz sunucu tarafı mesajlar yardımcı olabilir. UI ton ve düzen kontrolüne ihtiyaç duyuyorsa istemci tarafı çeviriler daha kolaydır. Birçok takım hibrit kullanır: API sabit bir kod, bir mesaj anahtarı ve parametreler döndürür; istemci en uygun gösterim metnini seçer.

API hata sözleşmesi için mesaj anahtarları (message keys) sert cümlelerden daha güvenlidir. API şu şekilde dönebilir: message_key: "auth.too_many_attempts" ve params: {"retry_after_seconds": 300}. UI bunu çevirir ve biçimlendirir, anlamı değiştirmez.

Çoğullaştırma ve geri dönüş (fallback) kuralları beklenenden daha önemlidir. Her dil için doğru çoğullaştırma kurallarını destekleyen bir i18n altyapısı kullanın. Bir fallback zinciri tanımlayın (ör. fr-CA -> fr -> en) böylece eksik dizeler boş ekrana dönüşmez.

İyi bir koruma: çevirilmiş metinleri kesinlikle kullanıcıya yönelik tutun. Stack trace, dahili ID'ler veya "neden başarısız oldu" ayrıntılarını yerelleştirilmiş dizelere koymayın. Hassas ayrıntıları görüntülenmeyen alanlarda (veya loglarda) tutun ve kullanıcılara güvenli, uygulanabilir metinler verin.

Arka uç hatalarını kullanıcıların takip edebileceği UI ipuçlarına dönüştürme

Çoğu arka uç hatası mühendisler için faydalıdır, ancak çok sık ekrana "Bir şeyler yanlış gitti" olarak düşer. İyi bir hata sözleşmesi, ayrıntıları sızdırmadan hataları net bir sonraki adıma dönüştürür.

Basit bir yaklaşım: hataları üç kullanıcı eyleminden birine eşleyin: girdiyi düzelt (fix input), yeniden dene (retry) veya destekle iletişime geç (contact support). Bu, arayüzü web ve mobil arasında tutarlı kılar.

• Fix input: doğrulama hatası, format hatası, zorunlu alan eksik.
• Retry: zaman aşımı, geçici üst sistem sorunları, oran sınırlaması.
• Contact support: izin sorunları, kullanıcı çözümleyemeyeceği çatışmalar, beklenmeyen dahili hatalar.

Alan ipuçları uzun mesajlardan daha önemlidir. Arka uç hangi alanın hatalı olduğunu biliyorsa, makine-okunur bir gösterici döndürün (ör. email veya card_number) ve arayüzün satır içinde gösterebileceği kısa bir neden verin. Birden fazla alan hatalıysa hepsini döndürün ki kullanıcı hepsini tek seferde düzeltebilsin.

UI desenini duruma göre eşlemek de yardımcı olur. Geçici yeniden deneme mesajı için bir toast yeterlidir. Girdi hataları satır içinde gösterilmelidir. Hesap ve ödeme engelleyicileri genellikle bloklayıcı bir diyalog gerektirir.

Tutarlı olarak güvenli sorun giderme bağlamı ekleyin: trace_id, bir zaman damgası varsa ve önerilen bir sonraki adım (ör. yeniden deneme gecikmesi). Böylece ödeme sağlayıcı zaman aşımı "Ödeme servisi yavaş. Lütfen tekrar deneyin" ile bir yeniden deneme düğümü gösterebilir; destek aynı trace_id ile sunucu tarafı hatayı bulur.

Adım adım: sözleşmeyi uçtan uca devreye alma

Bir API hata sözleşmesini devreye almak küçük bir ürün değişikliği gibi ele alındığında en iyi çalışır; yeniden düzenleme gibi değil. Kademeli ilerleyin ve destek ile UI ekiplerini erken dahil edin.

Kullanıcıya hızlı fayda sağlayıp istemcileri kırmadan uygulanabilecek bir yayılma sırası:

1. Mevcut durumun envanterini çıkarın (domain'e göre gruplayın). Loglardan gerçek hata yanıtlarını dışarı aktarın ve auth, signup, billing, file upload, permissions gibi kovalar halinde gruplayın. Tekrarlara, belirsiz mesajlara ve aynı başarısızlığın beş farklı biçimde ortaya çıktığı yerlere bakın.
2. Şemayı tanımlayın ve örnekleri paylaşın. Yanıt şeklini, gerekli alanları ve domain başına örnekleri dokümante edin. Sabit kod adları, yerelleştirme için bir mesaj anahtarı ve isteğe bağlı UI ipucu bölümü ekleyin.
3. Merkezi bir hata eşleyici uygulayın. Biçimlendirmeyi tek bir yerde tutun ki her uç nokta aynı yapıyı döndürsün. Üretilmiş bir backend'te (veya AppMaster gibi kodsuz bir back-end'de) bu genellikle her uç noktanın veya iş sürecinin çağırdığı ortak bir "hata-yanıta-eşle" adımı demektir.
4. UI'yi kodlara göre yorumlayacak şekilde güncelleyin. UI'ın mesaj metnine değil kodlara dayanmasını sağlayın. Kodları kullanarak bir alanı vurgulama, yeniden deneme eylemi gösterme veya destekle iletişim önerme kararlarını verin.
5. Logging ve destek için trace_id ekleyin. Her istek için bir trace_id oluşturun, ham hata ayrıntılarını sunucuda loglayın ve bunu hata yanıtına ekleyin ki kullanıcılar kopyalayabilsin.

İlk geçişten sonra, sözleşmeyi birkaç hafif dokümanla sabit tutun: domain başına ortak bir hata kodu kataloğu, yerelleştirme dosyaları, kod -> UI ipucu/sonraki eylem eşleme tablosu ve destek için "trace_id'nizi gönderin" ile başlayan bir oyun kitabı.

Legacy istemciler varsa, kısa bir kullanımdan kaldırma penceresi için eski alanları tutun; ancak yeni tek-seferlik biçimler oluşturmaya hemen son verin.

Desteği zorlaştıran yaygın hatalar

Çoğu destek sıkıntısı "kötü kullanıcılar"dan gelmez. Belirsizlikten gelir. API hata sözleşmeniz tutarsız olduğunda, her ekip kendi yorumunu üretir ve kullanıcılar harekete geçirilemeyen mesajlarla kalır.

Yaygın bir tuzak HTTP durum kodlarını tüm hikaye gibi görmektir. "400" veya "500" kullanıcının ne yapması gerektiği hakkında neredeyse hiçbir şey söylemez. Durum kodları taşıma ve geniş sınıflandırma için faydalıdır, ancak uygulama seviyesinde anlamı sabit bir kodunuz olmalıdır.

Bir diğer hata kodun zaman içinde anlamının değişmesidir. PAYMENT_FAILED önce "kart reddedildi" demekken sonra "Stripe kapalı" anlamına gelirse, UI ve dokümanlar yanlış olur. Destekte "Üç kart denedim ama hâlâ başarısız" gibi talepler gelirken gerçek sorun bir kesinti olabilir.

Ham istisna metnini (ve daha kötüsü stack trace'i) döndürmek hızlı olduğu için çekicidir. Kullanıcılar için nadiren faydalıdır ve iç ayrıntı sızdırabilir. Ham tanıları yanıtlarda değil loglarda tutun.

Bazı düzenler sürekli gürültü yaratır:

• UNKNOWN_ERROR gibi catch-all kodlarını aşırı kullanmak kullanıcıyı yönlendirme şansını ortadan kaldırır.
• Açık bir taksonomi olmadan çok fazla kod oluşturmak panoları ve oyun kitaplarını yönetmeyi zorlaştırır.
• Kullanıcıya yönelik metni geliştirici tanılarıyla aynı alanda karıştırmak yerelleştirme ve UI ipuçlarını kırılgan yapar.

Basit bir kural yardımcı olur: kullanıcı kararı başına bir sabit kod. Kullanıcı girdisini değiştirerek düzeltebiliyorsa belirli bir kod ve net bir ipucu kullanın. Düzeltemiyorsa (ör. sağlayıcı kesintisi), kod sabit kalsın ve güvenli bir mesaj ile "Daha sonra tekrar deneyin" gibi bir eylem ve destek için bir korelasyon ID'si verin.

Yayın öncesi hızlı kontrol listesi

Yayına almadan önce hataları bir ürün özelliği gibi ele alın. Bir şey başarısız olduğunda kullanıcı ne yapacağını bilmeli, destek olayı kolayca bulabilmeli ve istemciler arka uç değiştiğinde bozulmamalıdır.

• Her yerde aynı şekil: her uç nokta (auth, webhooks, dosya yüklemeleri dahil) tutarlı bir hata zarfı döndürsün.
• Sabit, sahiplenilmiş kodlar: her kodun net bir sahibi olsun (Payments, Auth, Billing). Aynı kodu farklı anlamlar için tekrar kullanmayın.
• Güvenli, yerelleştirilebilir metinler: kullanıcıya gösterilen metin kısa olsun ve gizli bilgileri içermesin (tokenlar, tam kart verisi, ham SQL, stack trace).
• Net UI sonraki adımı: en sık görülen hata tipleri için UI tek bir belirgin sonraki adım göstersin (tekrar dene, alanı güncelle, farklı ödeme yöntemi kullan, destekle iletişime geç).
• Desteğe izlenebilirlik: her hata yanıtı trace_id (veya benzeri) içersin; destek bunu isteyebilsin ve log/monitoring ile tam olay hızla bulunabilsin.

Gerçekçi birkaç akışı uçtan uca test edin: hatalı girdiyle bir form, süresi dolmuş oturum, oran sınırlaması ve üçüncü taraf kesintisi. Hatanın bir cümleyle açıklanıp ilgili trace_id ile loglarda bulunamıyorsa, yayına hazır değilsiniz.

Örnek: Kullanıcının toparlanabileceği kayıt ve ödeme hataları

İyi bir API hata sözleşmesi aynı hatayı üç yerde anlaşılır kılar: web UI'nızda, mobil uygulamanızda ve başarısız bir denemeden sonra gönderilecek otomatik e-postada. Ayrıca destek, her şeyi ekran görüntüsü istemeden yardım edecek kadar ayrıntı alır.

Kayıt: kullanıcının düzeltebileceği doğrulama hatası

Kullanıcı sam@ gibi bir e-posta girip Kaydol'a dokunur. API sabit bir kod ve alan düzeyinde bir ipucu döndürür, böylece tüm istemciler aynı alanı vurgular.

{
  \"error\": {
    \"code\": \"AUTH.EMAIL_INVALID\",
    \"message\": \"Enter a valid email address.\",
    \"i18n_key\": \"auth.email_invalid\",
    \"params\": { \"field\": \"email\" },
    \"ui\": { \"field\": \"email\", \"action\": \"focus\" },
    \"trace_id\": \"4f2c1d...\"
  }
}

Web'de e-posta kutusunun altında mesajı gösterirsiniz. Mobilde e-posta alanına odaklanıp küçük bir uyarı gösterirsiniz. E-postada: "Hesabınız oluşturulamadı çünkü e-posta adresi eksik görünüyor." diyebilirsiniz. Aynı kod, aynı anlam.

Ödeme: kullanıcının yönlendirilebileceği güvenli açıklama

Kart ödemesi başarısız olur. Kullanıcıya rehberlik etmek gerekir ama işlemci iç ayrıntılarını göstermemelisiniz. Sözleşmeniz, kullanıcıya gösterilen ile destekte doğrulanabilen bilgileri ayırabilir.

{
  \"error\": {
    \"code\": \"PAYMENT.DECLINED\",
    \"message\": \"Your payment was declined. Try another card or contact your bank.\",
    \"i18n_key\": \"payment.declined\",
    \"params\": { \"retry_after_sec\": 0 },
    \"ui\": { \"action\": \"show_payment_methods\" },
    \"trace_id\": \"b9a0e3...\"
  }
}

Destek trace_id isteyip dönen sabit kodu, reddin kalıcı mı yoksa yeniden denene bilir mi olduğunu, hangi hesap ve tutarla ilişkili olduğunu ve arayüze ipucunun gönderilip gönderilmediğini doğrulayabilir.

İşte API hata sözleşmesinin getirisi: web, iOS/Android ve e-posta akışlarınız, arka uç sağlayıcısı veya dahili hata ayrıntıları değişse bile tutarlı kalır.

Hata sözleşmenizi zaman içinde test etme ve izleme

API hata sözleşmesi ship edildiğinde "tamam" olmaz. Gerçekten tamamlanmış sayılırken aynı hata kodu aylar sonra bile aynı kullanıcı eylemine yol açıyor olmalıdır.

Dışarıdan bir istemci gibi test etmeye başlayın. Desteklediğiniz her hata kodu için en az bir isteğin bunu tetiklemesini yazın ve gerçekten dayandığınız davranışı doğrulayın: HTTP status, code, localization key ve UI ipucu alanları (hangi form alanının vurgulanacağı gibi).

Küçük bir test seti çoğu riski kapatır:

• her hata durumu için bir başarılı yol testi (kazara aşırı doğrulamayı yakalamak için)
• her sabit kod için dönen UI ipuçları veya alan eşlemesini kontrol eden bir test
• bilinmeyen hataların güvenli bir genel kod döndürdüğünü doğrulayan bir test
• her desteklenen dil için yerelleştirme anahtarlarının varlığını doğrulayan bir test
• istemci yanıtlarında hassas ayrıntıların asla görünmediğini doğrulayan bir test

İzleme ise testlerin kaçırdığı regresyonları yakalamanın yoludur. Hata kodlarının zaman içindeki sayımlarını izleyin ve ani sıçramalarda alarm kurun (ör. bir sürüm sonrası bir ödeme kodunun iki katına çıkması). Üretimde ortaya çıkan yeni kodları takip edin. Dokümante listenizde olmayan bir kod görünürse, muhtemelen biri sözleşmeyi atlamıştır.

Hangi bilgilerin istemcilere gideceğine erken karar verin. Pratik bir ayrım: istemcilere sabit kod, yerelleştirme anahtarı ve kullanıcı eylem ipucu verilir; loglara ham istisna, stack trace, istek ID'si ve bağımlılık hataları gider.

Ayda bir hata incelemesi yapın: en çok görülen beş kodu seçin ve her biri için birkaç destek kaydını okuyun. Kullanıcılar aynı takip sorusunu sormaya devam ediyorsa, UI ipucu eksik ya da mesaj çok belirsiz demektir.

Sonraki adımlar: deseni ürününüze ve iş akışlarınıza uygulama

Kafa karışıklığının en maliyetli olduğu yerlerden başlayın: en yüksek bırakılma oranına sahip adımlar (çoğunlukla kayıt, ödeme veya dosya yükleme) ve en çok destek talebi üreten hatalar. Önce bunları standartlaştırın ki sprint içinde etkisini görebilin.

Uygulamayı odaklı tutmanın pratik bir yolu:

• en çok destek üreten ilk 10 hatayı seçip sabit kodlar ve güvenli varsayımlar atayın
• kod -> UI ipucu -> sonraki eylem eşlemelerini yüzey (web, mobil, admin) bazında tanımlayın
• yeni uç noktalar için sözleşmeyi varsayılan yapın ve eksik alanları inceleme hatası sayın
• küçük bir dahili oyun kitabı tutun: her kodun ne anlama geldiği, destek ne sormalı ve sorumlusu kim
• birkaç metrik takip edin: kod bazlı hata oranı, "bilinmeyen hata" sayısı ve kod başına bağlanan ticket hacmi

AppMaster (appmaster.io) ile geliştiriyorsanız, bunu erken yerleştirmek faydalıdır: uç noktalarınız için tutarlı bir hata şekli tanımlayın, sonra web ve mobil ekranlarda sabit kodları UI mesajlarına eşleyin ki kullanıcılar her yerde aynı anlamı alsın.

Basit bir örnek: destek sürekli "Ödeme başarısız" şikayetleri alıyorsa, standartlaştırma sayesinde UI bir kod için "Kart reddedildi" diyebilir ve başka bir kod için "Ödeme sistemi geçici olarak kullanılamıyor" ile yeniden deneme düğümü gösterebilir. Destek tahmin yürütmek yerine trace_id isteyebilir.

Periyodik temizlik takviminiz olsun. Kullanılmayan kodları emekliye ayırın, belirsiz mesajları sıkılaştırın ve yüksek hacim olan yerlere yerelleştirme ekleyin. Sözleşme sabit kalırken ürün değişmeye devam edebilir.