RESTful olmayan bir HTTP API'si ne çağrılır? [kapalı]

HTTP tabanlı bir API'ye ne ad verirsiniz, kaynakları adlandırmak için URI'yi ve bu kaynakları işlemek için HTTP fiillerini (PUT, POST, DELETE, GET ...) kullanırsınız?

Roy Fielding'in şikayetlerine göre REST değil, çünkü hiper medya yok.

Dahili olarak, ekibimde herkes buna "REST API" diyor. Ben buna "REST benzeri" diyorum ama açıklayıcı değil ve anlamı bulanık. Kafam karıştı, çünkü REST konusunda büyük bir anlaşmazlık var. Alev savaşlarına katılmak istemiyorum ama sadece doğru terimleri kullanın.

Bir HTTP API olarak adlandırın .

HTTP standartlarına uygundur ve üstüne katmanlı başka bir şey yoktur (örn. SOAP).

HTTP standartları, kaynakları, fiilleri, başlıkları, içerik pazarlığını vb. Tanımlar.

REST (Resmi Devlet Transferi), mevcut HTTP standartlarına uygun olan gereksinimleri olan bir mimaridir, ancak HTTP kendi başına çalışır.

Deneyimlerime göre, "REST HTTP API'lerinin"% 90'ı kendilerini "sadece" bir HTTP API olarak adlandırmalıdır.

REST etiketini bırakmaktan utanmayın. Mikro hizmetlerde ve ilişkisel olmayan veritabanlarında olduğu gibi, havalı olmak için RESTful bir API'niz olması gerekmez. Roy yapabileceği en uzun ömürlü, en geriye dönük uyumlu ağ uygulama mimarisini yaratmaya başladı. İyi bir iş yaptı. Ancak her şey 40 yıldan fazla uyumluluk gerektirmez.

Richardson Olgunluk Modelleri böyle gider

0. Her yerde POST. Tek bir son nokta. (SABUN)
1. Her yerde POST. Birden fazla son nokta. (Kaynaklar)
2. HTTP VERBS. Birden fazla son nokta.
3. 2 gibi ve kaynaklara bağlantılar döndürür. (Dinlendirici)

Bu yüzden modele göre richardson seviye 2'ye uygun bir web servisi veya bu hatlar boyunca bir şey olarak adlandıracağım.

http://martinfowler.com/articles/richardsonMaturityModel.html

Hypermedia, REST benzeri API'lerle hiçbir zaman gerçekten popüler olmadı - bir API aslında hiper medya navigasyonunu uyguladığında, RESTful teriminin basitçe diğer "RESTful" web API'lerinden ayırmak için yeterli olmadığı anlamına geliyor. REST her şeyi yakalayabilen bir terim veya herhangi bir kaynak tabanlı web API'si haline geldi ve Hypermedia API gibi yeni isimler  , hiper medya konseptine odaklanmak için çağrıldı.

Yanlış terimlerin kullanılmasını savunmak istemiyorum, ancak REST'in genel modern yorumlamasının çoğu insan için tek tip URL'ler ve HTTP fiilleri kullanmak anlamına geldiğini düşünüyorum. Doğru değil, ancak Fieldings'in tanımını bilen herkes, diğerlerinin bilmediğini de bilmelidir. Öte yandan, yalnızca mevcut "RESTful" API'lerin nasıl uygulandığını gözlemleyerek REST'i bilen herhangi biri, HATEOAS veya isteğe bağlı kod gibi daha az bilinen REST kısıtlamalarından bahsettiğinizde ne hakkında konuştuğunuzu bilmeyecektir. Fielding bundan hoşlanmayabilir, ama orijinal tanımına geri dönmenin geç olduğunu düşünüyorum *. Ve dürüst olalım: Birisinin ilk kez REST API'si hakkında konuştuğunu duyarsanız, anında hypermedia içermediğini varsayıyorsunuz, değil mi?

RESTful'ın doğru tanımında ısrar etmek, genellikle sadece ek karışıklık yaratır. Zaman içinde anlamlarını değiştiren veya kitlelerin yanlış kabul ettiği birçok terimde olduğu gibi, eğer birileri orijinal tanımı biliyorsa, ancak REST'in daha geniş ve modern yorumunu kullanan birisini düzeltirsem, takdir ediyorum.

_{* ve aynı zamanda, bu konuda REST benzeri hipermedia olmayan API'ler için yeni terimler belirlemeye geç kaldılar. Onları nasıl arayabiliriz? ... RESTish ?}

HTTP üzerinden bir CRUD arayüzüdür (Yarat, Oku, Güncelle, Sil).

Bu iddiayı destekleyecek herhangi bir otorite düşünemiyorum, umarım daha iyi cevaplar alırsınız.

Ne istersen diyebilirsin, insanlar (neredeyse dini olarak) takip etmediğin REST 'özelliğinin' herhangi bir parçasına takılma eğilimindedir ve bunu gelişime son derece zararlı bir protesto noktası olarak kullanırlar. Ancak, basit gerçek şu ki, API hizmetleri için doğru REST uygulayan (neredeyse) sıfır servis var.

Ekibimizde Stateless APIgeliştirme aşamasındayken bizim adımızı koyduk, çünkü değiştirdiğimiz eski bir Durumsal ve İşlevsel SOAP API'simiz vardı (eski API'nin kendisi de hiçbir zaman kabul görmüş ve anlamlı bir isme sahip değildi. ).

Şimdi bu projenin sadece basit bir adı verilen bir API'si var the <project> API. Sonunda değiştirdiğimizde, yeni API sadece olarak bilinir the new <project> API.

Herhangi bir fantezi ve açıklayıcı iç isim vermek, bunu diğerlerinden ayırmanız gerekecek kadar fazla API'niz olmadığı sürece (bu durumda muhtemelen diğerlerini de yeniden adlandırmanız gerekir), neredeyse anlamsızdır.

Bunu bir çağırabilir Web API . Çok geniş bir terimdir, ancak diğer API tipi tanımlarının anlamı hakkında nitetmeden kaçınabilir. Terim, HTTP API gibi alternatiflerle karşılaştırıldığında daha az teknik ve kesindir , ancak teknik olmayan insanlarla konuşurken bu bir avantaj olabilir.

Bu terim ayrıca Leonard Richardson ( daha önce başka bir cevapta belirtilen Richardson Olgunluk Modelini tanımlayan - bir API'nin REST mimarisine ne kadar yakın olduğu konusunda iyi kabul edilmiş bir ölçüm) tarafından da kullanılır. Bir " RESTful Web API " nin "RESTful" bölümünü düşürürseniz elde edersiniz .