Jak nazwać interfejs API HTTP, który nie jest RESTful? [Zamknięte]

Jak nazwałbyś API oparte na HTTP, które używa URI do nazywania zasobów i czasowników HTTP (PUT, POST, DELETE, GET ...) do manipulowania tymi zasobami?

Według skarg Roya Fieldinga nie jest to REST, ponieważ nie ma hipermediów.

Wewnętrznie w moim zespole wszyscy nazywają to „REST API”. Nazywam to „REST-like”, ale nie jest opisowe, a jego znaczenie jest rozmyte. Jestem dość zdezorientowany, ponieważ istnieje ogromna różnica zdań na temat REST. Nie chcę brać udziału w wojnach z ogniem, ale używaj tylko poprawnych terminów.

Nazwij to HTTP API .

Jest zgodny ze standardami HTTP i nie ma na sobie żadnych innych warstw (np. SOAP).

Standardy HTTP definiują zasoby, czasowniki, nagłówki, negocjacje treści itp.

REST (REpresentational State Transfer) to architektura z wymaganiami, które mogą być dostosowane do istniejących standardów HTTP, ale HTTP działa samodzielnie.

Z mojego doświadczenia wynika, że ​​90% „interfejsów API REST HTTP” powinno nazywać się „tylko” interfejsem API HTTP.

Nie wstydź się zrezygnować z etykiety REST. Podobnie jak w przypadku mikrousług i nierelacyjnych baz danych, nie musisz mieć interfejsu API RESTful, aby być cool. Roy postanowił stworzyć najdłużej działającą, najbardziej kompatybilną wstecz, architekturę aplikacji sieciowych, jaką mógł. Wykonał dobrą robotę. Ale nie wszystko wymaga ponad 40 lat kompatybilności.

Modele dojrzałości Richardsona wyglądają następująco

0. POST wszędzie. Pojedynczy punkt końcowy. (MYDŁO)
1. POST wszędzie. Wiele punktów końcowych. (zasoby)
2. CZASOWNIKI HTTP. Wiele punktów końcowych.
3. Jak 2 i zwraca linki do zasobów. (Spokojny)

Więc zgodnie z modelem nazwałbym to usługą internetową zgodną z poziomem 2 Richardsona lub coś w tym stylu.

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

Hipermedia nigdy tak naprawdę nie stała się popularna wśród interfejsów API podobnych do REST - do tego stopnia, że ​​kiedy interfejs API faktycznie implementuje nawigację hipermedialną, termin RESTful po prostu nie wystarcza, aby odróżnić go od innych interfejsów API „RESTful”. REST stał się terminem uniwersalnym lub dowolnymi opartymi na zasobach interfejsami API sieci Web, a nowe nazwy, takie jak Hypermedia API  , zostały wymyślone, aby skupić się na koncepcji hipermedia.

Naprawdę nie chcę zalecać stosowania niepoprawnych terminów, ale myślę, że ogólna nowoczesna interpretacja REST oznacza po prostu używanie jednolitych adresów URL i czasowników HTTP dla większości ludzi. To nieprawda, ale każdy, kto zna definicję Fieldingsa, powinien również wiedzieć, że wielu innych nie. Z drugiej strony, każdy, kto zna REST tylko obserwując, w jaki sposób zaimplementowane są istniejące interfejsy API „RESTful”, nie będzie wiedział, o czym mówisz, gdy wspomnisz o mniej znanych ograniczeniach REST, takich jak HATEOAS lub kod na żądanie. Fieldingowi może się to nie podobać, ale myślę, że jest za późno, aby wrócić do pierwotnej definicji *. I bądźmy szczerzy: jeśli po raz pierwszy usłyszysz, jak ktoś mówi o jego interfejsie API REST, natychmiast zakładasz, że nie zawiera on hipermediów, prawda?

Naleganie na poprawną definicję RESTful zwykle powoduje dodatkowe zamieszanie. Podobnie jak w przypadku wielu terminów, które z czasem zmieniły swoje znaczenie lub które masy po prostu źle przyjęły, doceniam, jeśli ktoś zna oryginalną definicję, ale nie poprawiłbym nikogo, kto używa szerszej współczesnej interpretacji REST.

_{* a także za późno na ustanowienie nowych warunków dla interfejsów API podobnych do REST, które nie są hipermedialne. Jak powinniśmy do nich zadzwonić? ... RESTish ?}

Jest to interfejs CRUD (twórz, czytaj, aktualizuj, usuwaj) przez HTTP.

Nie mogę wymyślić żadnego organu, który poparłby to twierdzenie, więc mam nadzieję, że otrzymacie więcej i lepsze odpowiedzi.

Możesz to nazwać, jak chcesz, ludzie mają tendencję (prawie religijnie) zaczepiać się o dowolną część „specyfikacji” REST, której nie przestrzegasz, i używać jej jako protestu, który jest bardzo szkodliwy dla rozwoju. Ale to powiedziawszy, prosty fakt jest taki, że istnieją (prawie) zero usług, które implementują prawdziwy REST dla swoich interfejsów API.

W naszym zespole nazwaliśmy nasz w Stateless APIczasie, gdy był w fazie rozwoju, ponieważ mieliśmy wcześniejszy stanowy i funkcjonalny interfejs API SOAP, który zastępowaliśmy (sam interfejs API nigdy nie miał uzgodnionej i znaczącej nazwy, więc nie daliśmy się wciągnąć w nazwy) ).

Teraz ten projekt ma tylko jeden interfejs API, który jest po prostu nazywany the <project> API. Kiedy w końcu go zastąpimy, nowy interfejs API będzie po prostu znany jako the new <project> API.

Nadawanie mu jakiejkolwiek wymyślnej i opisowej nazwy wewnętrznej jest prawie bez znaczenia, chyba że masz tyle interfejsów API, że musisz odróżnić ten od reszty (w takim przypadku prawdopodobnie powinieneś również zmienić nazwy wszystkich pozostałych).

Możesz to nazwać Web API . Jest to bardzo szeroki termin, ale można uniknąć nieporozumień na temat znaczenia innych definicji typów API. Termin jest mniej techniczny i precyzyjny w porównaniu do alternatyw, takich jak HTTP API , ale może to być zaletą w rozmowach z osobami nietechnicznymi.

Termin ten jest także używany przez Leonarda Richardsona (który zdefiniował Model Dojrzałości Richardsona, o którym wspomniano już inną odpowiedź - dobrze przyjęty pomiar zbliżenia interfejsu API do architektury REST). To jest to, co dostajesz, jeśli upuścisz część „RESTful” „ RESTful Web API ”.