REST URI'sindeki eylemleri (fiiller) temsil etme

Müşteri belgelerim için gerçekleştireceğim bir yazdırma işlemim var. Ekleme, güncelleme, silme gibi diğer standart işlemlerin de gerçekleştirilmesi gerekiyor. yani, ben var:

• Yeni müşteri oluşturmak için:
  URI = / customer / {id}, = POST, Methodname = CreateCustomer ()
• Güncelleme için:
  URI: / customer / {id}, = PUT, method = UpdateCstomer () yazın
• Müşteriyi sil:
  URI = / customer / {id} için = DELETE, Methodname = DeleteCustomer () yazın
• Görünüm için:
  URI: / customer / {id}, = GET, method = GetCustomer () yazın

Şimdi, o müşteri için bir belge yazdırmam gerekirse, bir yazdırma işlevine ihtiyacım var. URI'm şöyle görünebilir: / customer / {id}, type = POST, method = PrintCustomer (). Ancak CreateCustomer için bu URI ve POST türünü kullandım. URI'nin şöyle görünmesini istedim: / customer / Print / {id}, type = POST, method = PrintCustomer ().

Ama URI'mde "Yazdır" fiili olamaz. Bunu yapmanın en iyi yolu nedir? / Customer / document / {id} 'ı URI olarak düşündüm ... ama aynı sorunla karşılaşacağım. "Belge" üzerinde CRUD işlemleri olurdu. Bu yüzden, yine "baskı" için kullandığım şey tükendi. Tavsiye lütfen.

POST"yarat" anlamına gelmez, "süreç" demektir. Mevcut bir kaynağa uygun bir istek göndererek yeni bir kaynak oluşturabilirsiniz (örneğin /customers, yeni bir müşteri oluşturmak için gönder). Ancak POST, düzgün bir CRUD paradigmasına karşılık gelmeyen diğer tüm eylemleri doldurmak için de kullanabilirsiniz .

Yazdırma durumunda, yazdırma işlemini bir kaynağın kendisi olarak düşünmelisiniz. Sistemden sizin için bir "yazdırma işi" yaratmasını istiyorsunuz. Bu, prints/istenen tüm baskılar için kap görevi gören bir kaynağa sahip olabileceğiniz anlamına gelir . Bir şey yazdırmak istediğinizde, POSTbu kaynağa, oluşturmak istediğiniz çıktıyla ilgili tüm bilgileri içeren ve yazdırmak istediğiniz kaynakları bunlarla bağlantılarla tanımlayan bir belgedir.

JSON belgesi olarak şöyle görünebilir:

{
   contents: ["http://site/customers/12345"],
   paper-size: "A4",
   duplex: "true"
}

Açıkçası, bunu yapmak istediğiniz şeyle alakalı olacak şekilde özelleştirmeniz gerekir. Önemli olan, URL'lerini belirterek yazdırılacak diğer kaynakları tanımlamanızdır.

İsteğe yanıt olarak, yalnızca bir 200 OKveya a 204 No-Contentdöndürüp bir ateşle ve unut işlemi olarak değerlendirebilirsiniz. Bunu geliştirmek istiyorsa Ancak, geri dönebilirler 201 Createdörn ve yeni oluşturulan baskı işinin URL belirtin /prints/12345.

Bir kullanıcı daha sonra GETyazdırma işinin durumunu (beklemede, devam ediyor, vb.) Görmek için kaynakta bir gerçekleştirebilir veya a DELETE.

Sorunu kaynak açısından yeniden ifade ettikten sonra, RESTful tasarımı doğal olarak gelmeli ve size hemen düşünmediğiniz şekillerde genişleme ve geliştirme fırsatı vermelidir.

Bunu daha önce yaptım. Bir belgeyi yazdırmak için yalnızca kaynağın pdf sürümünü döndürürüm. İstemcinin yalnızca Accept header application / pdf ile kaynak için bir GET isteği göndermesi gerekir.

Bu, yazdırma işi gibi geçici kaynak için yeni URI oluşturmayı da önler. HTTP üstbilgisini kullanmak da REST'in bir parçasıdır ve URI'yi temiz tutar.

Mevcut URI'nin GET'ine bir parametre eklemeniz yeterlidir

Birden fazla eylem için bir URI kullanmak oldukça tipiktir.

Aynı kaynaktan, ancak farklı bir işlemden bahsediyorsanız, bunu bir parametre olarak tanımlarsınız.

/ Müşteri / {id}? Baskı = true

Daha sonra GET yönteminizi tanımladığınız yerde print parametresinin varlığını algılar ve farklı şekilde ele alırsınız.

REST şu şekilde tanımlanır:

• POST - Kayıt, varlık veya kaynak oluşturma
• PUT - Güncelleme, kayıt, varlık veya kaynak
• SİL - Bir, kayıt, varlık veya kaynağı kaldırma

Öte yandan GET, bir kaynağın alınabileceği birçok farklı form olduğundan, birden çok şekilde kullanılması amaçlanmıştır. Bu nedenle GET istekleri bir sorgu dizesi olarak temsil edilir. Bir veritabanı kaynağıyla çalışıyorsanız, kelimenin tam anlamıyla bir sorgu yoluyla bir görünüm elde edersiniz, ancak REST kasıtlı olarak daha yüksek bir düzeye çıkarılır, çünkü birçok farklı türde kaynakla başa çıkmak için tasarlanmıştır.

REST spesifikasyonu, API'lerin son zamanlarda yoğun bir şekilde kullanmaya başlamasına rağmen oldukça ileriyi düşünüyor.

REST protokolleri hakkında daha fazla bilgi edinmek istiyorsanız " Haters Gonna Hate HATEOAS " ı okumanızı şiddetle tavsiye ederim .

Güncelleme:

@Shauna, akıl yürütmemde ilginç bir delik gösterdi. Hiçbir var gerçek doğru yolu ve birçok biçimi kabul edilebilir olarak kabul edilir. Bunu biraz daha düşündüm ve amaçlanan kullanımınız verileri farklı bir temsile dönüştürmek olduğundan, dönüşümü yeni bir MIME Tipi olarak tanımlamak mantıklıdır.

Örneğin, URI'yi şu şekilde temsil edebilirsiniz:

/customer/{id}+print

Yanıt İçeriği Türünü metne / html + print olarak ayarlayabileceğiniz yer. Bu şekilde gelecekte daha fazla dönüşüm tanımlama seçeneğiniz de olur.

Örneğin:

// for application/json
/customer/{id}+json

// for application/atom+xml
/customer/{id}+atom

Her iki durumda da, tüm formlar kabul edilebilir. Karar verdiğiniz uygulama daha çok kişisel tercihinize ve sunucunuzun yeteneklerine bağlıdır.

Kenara: Açıklığa kavuşturalım çünkü bir karışıklık var gibi görünüyor. Kaynağın nasıl dönüştürüleceğini belirtmek için 'yazdır' sorgu parametresi ve / veya içerik türü kullanılır. Fiziksel bir yazdırma işinin nasıl tetikleneceği değil. Güvenlik nedeniyle, donanım düzeyinde erişim her zaman kullanıcıya / istemciye / tarayıcıya bırakılır.