Soru Bir alt etki alanına veya bir alt klasöre REST API yerleştirmek daha mı iyi? [kapalı]


URL ile barındırılan bir web uygulamasına sahibiz http://example.com. Şimdi bu uygulamanın bir bölümünü huzurlu bir hizmet olarak genişletmek istiyoruz ve en iyi URL kalıbı üzerinde tartışıyoruz. Aradım ama somut bir yönlendirme bulamadı.

URL kalıbı olmalı mı? http://api.example.com veya http://exaple.com/api/v1?

Bunun için standart bir rehber var mı?


23
2018-01-28 03:12


Menşei


Başka şirket varlıklarında veya geliştirme ekibinin başka herhangi bir yerinde daha önce herhangi bir tecrübe var mı? Ya seçim iyi çalışırdı. - Andrew
Her ikisi de iyi görünüyor, projemizin birinde seçtik api.XXXXX.com biçim - Arun P Johny
Hatta işte aynı tartışmayı yaptık, api.xxxx.com ile gittik. Bu yaklaşım daha iyi görünüyordu. Artık API Kümesi için farklı kurulumlarımız var. - Srinivas
Bu sorunun gerçekten doğru bir cevabı yok. - Ryan Stewart


Cevaplar:


Bu sizin ihtiyaçlarınıza bağlıdır.

Eğer kullanırsan http://api.example.com API'nizi bir alt alan yapar. Temel olarak, REST hizmetinizin birden çok müşteri tarafından tüketilmesi gerekiyorsa bu URL modeli iyidir, ancak API'nize yalnızca bir müşteri bağlıysa http://example.com/api/v1 iyidir. Bununla birlikte, ona bağlı daha fazla müşteriyle daha fazla API eklemek istiyorsanız daha iyi olur http://example.com/api/v1. Örneğin, aşağıdakileri dikkate alın.

http://example.com/reportapi/apioperation?parameters

http://example.com/paymentapi/apioperation?parameters

http://example.com/searchapi/apioperation?parameters

Son olarak, PayPal modeli kullanır http://example.com/api/v1.


8
2018-01-28 03:28



Paypal API'leri biraz eski. Şerit api.stripe.com kullanıyor. Hatta SO api.stackoverflow.com kullanır. - Srinivas
Paypal o deseni kullanmaz. Paypal kullanır https://api.[sandbox].paypal.com/v1/ Desen - Green


Ben de kullanmamalısın. http://api.example.com ne de http://example.com/api/v1.

Bunun yerine kullanmanızı öneririm http://example.com/api ve sürüm oluşturma için içerik anlaşması.

İşte düşüncelerim neden:

Bir alt alanın kullanılması:

Başına URI Şeması ŞartnameAna makine üzerinde bir uygulamayı veya API'yi tanımlamak yerine, ana makinenizi tanımlamak için kullanılan URI'nin yetki bölümünde API'yi tanımlarsınız. API'nız için aslında farklı bir adres oluşturuyorsunuz. Bu, example.com için olduğu gibi kimlik doğrulamanın api.example.com için çalışmayabileceği anlamına gelir.

Bunun için geçerli bir sebep, mobil cihazlar için yeni bir örnek tasarlarken, örn. mobile.example.com, ancak bunu daha çok altyapıya dayalı bir karar olarak görüyorum.

Ana alanda bir dönüşümlenmemiş yol kullanmak:

Burada iki bilgi biti vardır: biri bir API kaynağı olduğunu ve ikincisinin o API kaynağının (v1) sürüm numarası olduğunu gösterir.

Kullanma konusunda kötü bir şey yok /api/ API ile, örneğin, web sitenizin altında çalışabilecek web görünümü arasında ayrım yapmak için /web/. Bu yaygın en iyi uygulama olarak düşünülebilir.

Bunu amaçladığınızdan emin değilim, ancak sorunuz API sürümünün nasıl çözüleceğine dair bir sorgu içeriyor. Şahsen, API sürümünün, mümkün olduğunca uzun süre kararlı kalması amaçlandığından, URL'ler kullanılarak yapılmaması gerektiğini düşünüyorum. Soğuk URI'ler değişmez! Bunun yerine, API'nizi sürüm etmek için HTTP İçerik Türü bilgilerini kullanmayı düşünün. Aslında bu yöntemi kullandım VMware belgeleri. Ayrıca burada oldukça eski, ama yine de yararlı, içerik türü sürümleri Peter Williams.


2
2017-10-06 13:42



Url'deki sürümün, "Cool URI'lerin değişmemesi" nin, sürüm için Content-Type kullanmanın daha iyi bir yolunu izlemesini istiyorum. Niye ya? Kullanıcılarınızın modelinin adını gelecekteki bir sürümde değiştireceğinizi varsayalım, böylece kullanıcıları yalnızca kullanıcılara yönlendiriyorsunuz. Ardından, daha sonraki bir noktada, kullanıcı adında yeni bir model eklemeyi seçersiniz. Şimdi, URL'yi değiştirmek zorundasınız. Bunun yerine, başlangıçta URL’de sürümleri kullanabilirdiniz. Daha sonra 100 yayınlar, eğer v1 api'nizi çalışır durumda tutarsanız, tüm v1 linkleri tam olarak aynı şekilde çalışır. Basit. (artı urller çoğunlukla üstbilgileri değiştirmek için daha kolaydır) - Ben Aubin
ben kesinlikle Bu cevaba katılma. Ben'in yorumu şöyle bir şey oluyor, ama bu çok açık değil. Önemli bir paket, birisinin uygulamasının işlevselliğini API'nize dayandırması durumunda, API’nizin her zaman ne verdiklerini kabul edip onlardan ne beklediklerini geri getireceğine dair bir garantiye ihtiyaçları vardır. URL'lerinizi yorumlamıyorsanız, iç uygulamalarınız değiştikçe ve değiştikçe belirli bir URL kaçınılmaz olarak sürüklenmeye başlar. - kael
% 100 katılmıyorum. Gerekirse, kimlik doğrulaması tüm alt etki alanlarında çalışabilir, ancak yine de API'nız için aynı hatayı (ör. API anahtarları) istemezsiniz. Üstelik, HTTP İçerik Türü çözümü gereksiz yere aşırı derecede karmaşıktır ve API'nın farklı sürümleri muhtemelen aynı URL'leri kullanmayacaktır. Sonuçta paylaşılan URL'lerde ve bazı diğer belirli kişilerde ... mükemmel karışıklık: / - Profet


Bu, tek bir en iyi çözüm bulunmayan bir zorlama durumudur.

Örneğin, eğer http://example.com/ API aracılığıyla standart bir web arayüzü üzerinden içerik sağlar, daha sonra http://api.example.com/api/<version>/<the usual resource pattern> API etkileşimli tarayıcı tabanlı uygulama erişimini ayırmak için. Bu mantıklı mı?

Örnek: api.rottentomatoes.com

Bununla birlikte, alan adınız API çağrılarına ayrılsa bile, yukarıdaki kalıbı kullanmak yine de anlamlıdır. http://example.com/ uygulamanızla etkileşimde bulunmanın diğer yolları için. Örneğin, isteyebilirsiniz http://example.com/mobile/, vb.


0
2018-01-28 06:23