RESTful API bir şeyin yokluğunu temsil eder

Bir kişinin ruh hayvanını seçip seçmediğini belirlemek için bir API düşünün. Sadece sıfır veya bir ruh hayvanına sahip olabilirler.

Şu anda:

/person/{id}/selectedSpiritAnimal

bir hayvan seçtiklerinde http 200 ve {selectedAnimal:mole}

ancak seçimleri olmadığında http 404 değerini döndürür.

Bu, benim bir ruh hayvanını HTTP hatası olarak - henüz bir ruh hayvanı seçmemiş olmakla - temsil ettiğimiz için ruh hayvanımı mutsuz ediyor.

Ayrıca, bir iş olarak - erm Sprit-Animal-Hampers-R-us - birisinin ne zaman seçimi olmadığını bilmek isteriz, böylece onları isteyebiliriz.

Burada daha iyi bir yanıt var:

HTTP 200 ve {selectedAnimal:null}

hatta daha açık

HTTP 200 ve {selectedAnimal:null, spiritAnimalSelected: false}

Yoksa 404'ü iade etmek daha mı iyi? this image has not yet been uploadedÇevrimiçi olarak bir görüntüyü izlerken olduğu gibi bir 404 olurdu. 404 this person has not selected a spirit animalolabilir

Bu soru kopya olarak önerildi, ancak bu soru, uygulama URL'nin temsil ettiği değişikliğe izin vermeyecek şekilde yapılandırıldığında istenen başka bir geçerli URL'yi ele alıyor.

Halbuki burada kaynağın yokluğunun anlamlı olduğu bir kaynağı nasıl temsil ettiğine bakıyorum. Yani istemcinin URL istemesi için geçerlidir ve yanıt, bir şeyin yokluğunu temsil eden kaynağı başarıyla talep etmiş olmanızdır.

Yani bu 'iş mantığı' değil, bir şeyin yokluğunun bir anlamı olduğu bir durum (meslektaşlarımın çoğu 404'ün hala doğru olduğunu iddia ediyor olabilir) ama bunu nasıl eşleştireceğimden emin değilim spec.

Bir cevap seçmek çok zor. Buradaki ve işte devam eden görüşmelerde fikrimi defalarca değiştirdim.

Benim için buraya yerleşen şey, specin müşterinin hata yaptığı bir 4xx olduğunu söylediğidir . Bu örnekte, istemciye seçilenSpiritAnimal URL'sinden bir yanıt beklemesi söylendi, bu nedenle hata oluşmadı.

Meslektaşlarım arasındaki fikir birliği, bunun kötü bir API tasarımının belirtisi olduğudur.

Muhtemelen / person / {id} 'i talep etmemiz ve kişi için bir dizi bağlantı ilişkisi döndürmemiz daha iyi olur ... o zaman / selectedSpiritAnimal bağlantısı (bir kişinin seçimi olmadığında) verilmezse, ancak yine de 404 mantıklı. Veya kısmi yanıtlar uyguladığınızı ve / / id / {id} istemcisinin verilerin bir alt kümesini istemediği sürece daha eksiksiz bir belge döndürmesine izin verdiğinizde

HTTP 4xx kodları muhtemelen bu senaryo için doğru seçim değildir. Sıfır ruhlu hayvanlara sahip olmanın geçerli bir durum olduğunu ve API yolunun person/{id}/selectedSpiritAnimalkişinin idsahip olup olmadığını hesaba katacağını belirtirsiniz .

HTTP 4xx yanıtları, bir istemcinin istekte yanlış bir şey yaptığı durum için ayrılmıştır (bkz. W3'ün orijinal teknik özellikler arşivi ). Ancak müşteri, idbir ruh hayvanına sahip olsun ya da olmasın, geçerli bir talepte bulunmaktadır .

Bu nedenle, yanıtta düzgün biçimlendirilmiş bir JSON gövdesi ve bir HTTP 2xx kodu kullanarak ikinci çözümlere yaslanıyorum.

Şimdi böyle bir istek alırsanız ve bu kişinin olmadığı ortaya çıkarsa id, 4xx kodu daha mantıklıdır.

Size Richardson Olgunluk Modeli'ni tanıtayım .

Sorununuz, hiper-medya ile gösterilen bir ilişkiye sahip iki kaynağınızın olması gereken iki kaynağı bir olarak temsil etmenizdir. İlişkileri tanımlamak için hipermedya kullanmak, Rest'in görkemli seviye 3'üdür.

Kişiniz URI altında yaşamalıdır /person/{id} ve hayvan altında yaşamalıdır /spiritanimal/{id}. Kişi, hayvana bir bağlantı kullanarak ruh hayvanına sahip olduğunu belirtmelidir.

Haydi Bob adında bir kimliği ve bir Unicorn ruhu hayvanı olan bir insan düşünelim.

GET /person/123

dönecekti;

{
  "name": "Bob",
  "links": [
    {
      "rel": "spiritanimal",
      "uri": "/spiritanimals/789"
    }
  ]
}

Şimdi, 123 kişisini okuyan herkes, bir ruh hayvanına sahip olduğunu ve daha fazla bilgi edinebilecekleri URI'ye sahip olduğunu bilecektir.

GET /spitiranimal/789

geri dönebilir

{
  "type": "Unicorn"
}

Şimdi Fred adında, 456 numaralı kimliği olan ve ruhu hayvanı olmayan bir insan düşünelim.

GET /person/456

dönecekti;

{
  "name": "Fred",
  "links": [
  ]
}

Şimdi 456 kişisini okuyan herkes, hiçbir ruh hayvanının olmadığını, bağlantı olmadığı için bilecektir. İlişki eksikliğini göstermek için herhangi bir HTTP durum kodu kullanmaya gerek yoktur.

Bu, ruh hayvanlarını almak için uygun url'dir; bu nedenle, 404 hatası uygun değildir. 404 mantık problemi değil, teknik problemi temsil etmek içindir.

Uygun çözüm http 200 ve {"selectedAnimal": null}

Geri dönen ayrı bir web metodunuz olmalıdır . Perde arkasında, aynı yöntem çağrıları yapılabilir veya yapılmayabilir, sadece null olursa yanlış döndürülür, ancak tüketen kod değil karar vermesi gerekir./person/{id}/hasSelectedSpiritAnimal{"isSpiritAnimalSelected": false}

Sorguları yakından ilişkili olsa bile, zorlayıcı bir neden olmadan ayrı sorguları tek bir web yönteminde birleştirmekten kaçınmak daha iyidir.

Son noktanızın temsil ettiği sadece bir hayvan değildir; bu bir hayvan ya da yokluğu. En iyi Optional/ Maybe/ Nullable/ vb. İle temsil edilen bir değerdir .

Bu nedenle geçerli değerler (200 OK'deki gibi) olabilir:

• {'animal': <some animal>, 'selected': true}
• {'animal': null, 'selected': false}

Bunu hayal olabilir DELETEbitiş noktasına uygulandığında yöntemini ayarlayabilirsiniz 'selected'için falseolduğunu, seçilen hayvan unset, yine.

Tabii ki, 'selected'anahtarı buraya bırakabilirsiniz , sadece netlik için gösterilir; string vs nullayrım için yeterlidir.

404 kullanmalısınız.

404 (Bulunamadı) durum kodu, kaynak sunucunun hedef kaynak için geçerli bir temsil bulamadığını gösterir

RFC7231

HTTP/1.1 200 OK
Content-Type: application/json
Date: Mon, 25 Sep 2017 00:00:00 GMT

"mole"

HTTP/1.1 404 Not Found
Content-Type: text/plain
Date: Mon, 25 Sep 2017 00:00:00 GMT

this person has not selected a spirit animal

Bir insan arabirimi değil, bir programlama arabirimi yaptığınız için, 404 metni isteğe bağlıdır.

Bunu tercih ederim çünkü standart protokolleri mümkün olduğunca tercih ederim. HTTP'nin var olmayanları temsil etmenin bir yolu vardır ve ben de bunu kullanırım.

EDIT: Kullanıcıların ruh hayvanlarını paylaşıp paylaşmayacaklarını seçebildikleri ve birisinin paylaşmadığı bir özellik eklediğinizi varsayalım. 200 OK nullveya 200 OK döndürür müsünüz "Unauthorized? Yoksa standart 401 Yetkisiz / 403 Yasak'ı kullanır mısınız? Bu, ilk etapta birini seçmemeye doğrudan benziyor.

Alternatif olarak, 200 OK + JSON kullanmak istiyorsanız, geri dönmelisiniz null.

HTTP/1.1 200 OK
Content-Type: application/json
Date: Mon, 25 Sep 2017 00:00:00 GMT

"mole"

HTTP/1.1 200 OK
Content-Type: application/json
Date: Mon, 25 Sep 2017 00:00:00 GMT

null

Her şeyi temiz tutun. Yalnızca gerekirse daha fazla sargı oluşturun.