Comment appeler une API HTTP qui n'est pas RESTful? [fermé]

Comment appelleriez-vous une API basée sur HTTP, qui utilise l'URI pour nommer les ressources et les verbes HTTP (PUT, POST, DELETE, GET ...) pour manipuler ces ressources?

Selon les plaintes de Roy Fielding, ce n'est pas REST, car il n'y a pas d'hypermédia.

En interne, dans mon équipe, tout le monde l'appelle "API REST". Je l'appelle "REST-like" mais ce n'est pas descriptif et sa signification est floue. Je suis assez confus à ce sujet, car il y a un énorme désaccord sur REST. Je ne veux pas participer à des guerres de flammes, mais utilisez simplement des termes corrects.

Appelez-le une API HTTP .

Il est conforme aux normes HTTP et n'a rien d'autre en couches (par exemple SOAP).

Les normes HTTP définissent les ressources, les verbes, les en-têtes, la négociation de contenu, etc.

REST (REpresentational State Transfer) est une architecture avec des exigences qui se prêtent aux normes HTTP existantes, mais HTTP fonctionne tout seul.

D'après mon expérience, 90% des "API HTTP REST" devraient s'appeler "juste" une API HTTP.

N'ayez pas honte de laisser l'étiquette REST. Comme pour les microservices et les bases de données non relationnelles, vous n'avez pas besoin d'avoir une API RESTful pour être cool. Roy a décidé de créer l'architecture d'application en réseau la plus durable et la plus rétrocompatible possible. Il a fait du bon travail. Mais tout ne nécessite pas plus de 40 ans de compatibilité.

Richardson Maturity Models va comme ça

0. POST partout. Un seul point de terminaison. (SAVON)
1. POST partout. Plusieurs points de terminaison. (Ressources)
2. VERBES HTTP. Plusieurs points de terminaison.
3. Comme 2 et renvoie des liens vers des ressources. (Reposant)

Donc, selon le modèle, je l'appellerais un service Web conforme au niveau richardson 2 ou quelque chose du genre .

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

Hypermedia n'est jamais vraiment devenu populaire avec les API de type REST - au point que lorsqu'une API implémente réellement la navigation hypermédia, le terme RESTful n'est tout simplement pas suffisant pour le distinguer des autres API Web "RESTful". REST est devenu un terme fourre-tout ou toute API Web basée sur les ressources et de nouveaux noms comme Hypermedia API  ont été inventés pour se concentrer sur le concept hypermédia.

Je ne veux pas vraiment préconiser l'utilisation de termes incorrects, mais je pense que l'interprétation moderne générale de REST signifie simplement utiliser des URL uniformes et des verbes HTTP pour la plupart des gens. Ce n'est pas correct, mais quiconque connaît la définition de Fieldings devrait également savoir que beaucoup d'autres ne le savent pas. D'un autre côté, quiconque ne connaît REST qu'en observant comment les API "RESTful" existantes sont implémentées ne sait pas de quoi vous parlez lorsque vous mentionnez des contraintes REST moins connues comme HATEOAS ou du code à la demande. Fielding peut ne pas l'aimer, mais je pense qu'il est trop tard pour revenir à la définition d'origine *. Et soyons honnêtes: si vous entendez quelqu'un parler de son API REST pour la première fois, vous supposez instantanément qu'elle n'inclut pas l'hypermédia, n'est-ce pas?

Insister sur la définition correcte de RESTful ne crée généralement qu'une confusion supplémentaire. Comme pour de nombreux termes qui ont changé de sens au fil du temps ou que les masses ont tout simplement mal adopté, j'apprécie que quelqu'un connaisse la définition d'origine, mais je ne corrigerais personne qui utilise l'interprétation moderne plus large de REST.

_{* et aussi trop tard pour établir de nouvelles conditions pour les API non hypermédia de type REST, d'ailleurs. Comment devrions-nous les appeler de toute façon? ... RESTAURER ?}

Il s'agit d'une interface CRUD (Créer, Lire, Mettre à jour, Supprimer) sur HTTP.

Je ne peux penser à aucune autorité pour étayer cette affirmation, alors j'espère que vous obtiendrez des réponses plus nombreuses et meilleures.

Vous pouvez l'appeler comme vous voulez, les gens ont tendance à (presque religieusement) s'accrocher à n'importe quelle partie de la `` spécification '' REST que vous ne suivez pas et à l'utiliser comme un point de protestation qui est très préjudiciable au développement. Mais cela dit, le simple fait est qu'il existe (presque) zéro service qui implémente le vrai REST pour leurs serveurs API.

Dans notre équipe, nous avons nommé la nôtre Stateless APIpendant qu'elle était en développement parce que nous avions une API SOAP dynamique et fonctionnelle héritée que nous remplaçions (l'API héritée elle-même n'a jamais eu de nom convenu et significatif non plus, donc nous n'avons pas été trop pris dans les noms ).

Maintenant, ce projet n'a qu'une seule API, il est simplement appelé the <project> API. Lorsque nous le remplacerons finalement, la nouvelle API sera simplement connue sous le nom de the new <project> API.

Lui donner un nom interne fantaisiste et descriptif n'a presque aucun sens, sauf si vous avez autant d'API que vous devez différencier celle-ci des autres (auquel cas vous devriez probablement renommer tous les autres également).

Vous pouvez l'appeler une API Web . C'est un terme très large, mais il peut éviter de tergiverser sur la signification des autres définitions de type d'API. Le terme est moins technique et précis par rapport à des alternatives comme l' API HTTP , mais cela pourrait être un avantage lorsque vous parlez à des personnes non techniques.

Ce terme est également utilisé par Leonard Richardson (qui a défini le modèle de maturité Richardson qui est déjà mentionné une autre réponse - une mesure bien acceptée de la proximité d'une API avec une architecture REST). C'est ce que vous obtenez si vous supprimez la partie "RESTful" d'une " API Web RESTful ".