Birden çok dil istemenin iki etkili yolunu tanımladınız. Her ikisi de iyi çalışmalıdır. Kendi kodum için açık dil isteği parametresini seçerdim.
TL; DR Backstory
Bir Accept-Language başlığı vardır . Not, Acceptdeğil Accepted. HTTP içerik anlaşmasının standart bir parçasıdır. Yanıt genellikle bir Content-Language üstbilgisini geri ayarlar .
Accept-Languagebir dizi seçenek sunan açılış teklifidir; Content-Languagehangi dilin seçildiğini belirten çözümdür. Çoğu Content-Languageyanıt tek bir dil döndürür, ancak yanıt dillerinin virgülle ayrılmış bir listesini sağlama seçeneği vardır. Genellikle bu karışık içeriktir, ancak birden fazla ayrık alternatifi gösterememesinin bir nedeni yoktur. İstemcinin kullanılabilir tüm dilleri istemesini istiyorsanız, zaten bir joker karakter isteği seçeneği vardır *.
Bu nedenle, kullanabileceğiniz bir HTTP başlık mekanizması zaten var. Bununla birlikte, bir dizi olası seçeneği sunan ve tek bir seçeneği geri alan bir müzakere sürecini piggyback yapacağınıza dikkat edin. "İşte bir seçenekler listesi, hepsini bana ver!" Eğer bu konuda bir fikriniz yoksa bir çözümünüz var.
Bununla birlikte, HTTP başlıklarında REST API parametrelerini sinyallemenin uygunluğu konusunda önemli tartışmalar vardır. Bu biraz garson veya garson görünmesini beklemek yerine, bir restoran girmek ve ana veya maître d 'için ayrıntılı sipariş bulanıklaştırma gibi. Çalışabilir ve örneğin, ana bilgisayara yönelik sipariş içecekler veya mezeler ile ilgiliyse iyi olabilir - ana bilgisayarın hızlı bir şekilde görebileceği veya sunucunuzla hızlı bir şekilde iletişim kurabileceği şeyler. Ancak, yanlış düzeyde / katmanda veya yanlış oyuncuya yönelik bir protokol ihlali olarak da görülebilir.
İkinci bir alternatif, açık bir istek parametresi olacaktır. Sen öner ?all_languages=true. Bu çok spesifik görünüyor. Böyle bir şey lang=en,fr,es(çoklu listelenmiş dilleri izin verilir) veya lang=*veyalang=all (mevcut her dil belirtin) daha genel görünüyor. Bu, URL'de veya istek gövdesinde ifade edilebilir.
Her iki durumda da, çok dilli yanıtınız iade edilen JSON yüküne kolayca kodlanabilir:
[ { "lang": "en", "content": "As Gregor Samsa awoke one morning..." },
{ "lang": "de", "content": "Als Gregor Samsa eines Morgens..." },
...
]
Sonunda, bu yaklaşımlardan herhangi birinin sizin için iyi çalışması gerekir. Her ikisi de "tutarlı, iyi yapılandırılmış RESTful API tasarımı" olarak görülebilir. Hangisinin daha iyi olduğu konusundaki kararlılık, çoğunlukla, piggybacking'in (ve tipik duygusunun hafifçe değiştirilmesinin) HTTP içerik anlaşması başlıklarının uygunluğuna yönelik tutumunuza dayanır.
Kendi tercihi olmaktır değil İntermiks başlıkları ve bir API isteği eşit parçaya gibi diğer parametreler. Açık langveya languageparametre benim için daha temiz görünüyor. Ama bu yana HTTP fiil (örneğin GET, PUT, POST, PATCH, ...) başlığının parçasıdır ve hiç / istek yorumlanması karışmış da kritik, ben zarf vs içeriği ayrım biraz yapay ve bulanık olduğunu kabul ediyorum. Çoğu tasarım kararında olduğu gibi, gerçek uzmanlar buna farklı cevap verir ve YMMV.