¿Cómo llamar a una API HTTP que no es RESTful? [cerrado]

¿Cómo llamaría a una API basada en HTTP que utiliza URI para nombrar recursos y verbos HTTP (PUT, POST, DELETE, GET ...) para manipular esos recursos?

Según las quejas de Roy Fielding, no es REST, porque no hay hipermedia.

Internamente, en mi equipo, todos lo llaman "API REST". Lo llamo "REST-like" pero no es descriptivo y su significado es confuso. Estoy bastante confundido al respecto, ya que hay un gran desacuerdo sobre REST. No quiero participar en las guerras de llamas, pero solo use los términos correctos.

Llámalo una API HTTP .

Se ajusta a los estándares HTTP y no tiene nada más en capas en la parte superior (por ejemplo, SOAP).

Los estándares HTTP definen recursos, verbos, encabezados, negociación de contenido, etc.

REST (REpresentational State Transfer) es una arquitectura con requisitos que cumplen con los estándares HTTP existentes, pero HTTP funciona por sí solo.

En mi experiencia, el 90% de las "API REST HTTP" deberían llamarse "solo" una API HTTP.

No se avergüence de dejar la etiqueta REST. Al igual que con los microservicios y las bases de datos no relacionales, no es necesario tener una API RESTful para ser genial. Roy se propuso crear la arquitectura de aplicaciones en red más duradera y compatible con versiones anteriores que pudiera. Hizo un buen trabajo. Pero no todo necesita más de 40 años de compatibilidad.

Los modelos de madurez de Richardson son así

0. Publicar en todas partes. Un único punto final. (JABÓN)
1. Publicar en todas partes. Múltiples puntos finales. (recursos)
2. VERBOS HTTP. Múltiples puntos finales.
3. Me gusta 2 y devuelve enlaces a los recursos. (Sosegado)

Entonces, según el modelo, lo llamaría un servicio web conforme al nivel 2 de richardson o algo por el estilo.

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

Hypermedia nunca se hizo realmente popular con las API similares a REST, hasta el punto de que cuando una API realmente implementa la navegación hipermedia, el término RESTful simplemente no es suficiente para distinguirlo de cualquier otra API web "RESTful". REST se ha convertido en un término general o en cualquier API web basada en recursos y  se han acuñado nuevos nombres como Hypermedia API para centrarse en el concepto hipermedia.

Realmente no quiero abogar por el uso de términos incorrectos, pero creo que la interpretación moderna general de REST simplemente significa usar URL uniformes y verbos HTTP para la mayoría de las personas. No es correcto, pero cualquiera que conozca la definición de Fieldings, también debería saber que muchos otros no. Por otro lado, cualquiera que conozca REST solo observando cómo se implementan las API "RESTful" existentes, no sabrá de qué está hablando cuando mencione restricciones REST menos conocidas como HATEOAS o código a pedido. Puede que a Fielding no le guste, pero creo que es demasiado tarde para volver a la definición original *. Y seamos honestos: si escuchas a alguien hablar sobre su API REST por primera vez, asumes instantáneamente que no incluye hipermedia, ¿no?

Insistir en la definición correcta de RESTful generalmente solo crea confusión adicional. Al igual que con muchos términos que han cambiado su significado con el tiempo o que las masas simplemente adoptaron mal, agradezco que alguien conozca la definición original, pero no corregiría a nadie que esté utilizando la interpretación moderna más amplia de REST.

_{* y también demasiado tarde para establecer nuevos términos para las API no hipermedia similares a REST, para el caso. ¿Cómo deberíamos llamarlos de todos modos? ... RESTATE ?}

Es una interfaz CRUD (Crear, Leer, Actualizar, Eliminar) a través de HTTP.

No puedo pensar en ninguna autoridad que respalde esta afirmación, así que espero que obtenga más y mejores respuestas.

Puede llamarlo como quiera, la gente tiende (casi religiosamente) a adherirse a cualquier parte de la 'especificación' REST que no está siguiendo y usar eso como un punto de protesta que es muy perjudicial para el desarrollo. Pero dicho esto, el simple hecho es que existen (casi) cero servicios que implementan REST verdadero para sus servicios API.

En nuestro equipo, nombramos el nuestro Stateless APImientras estaba en desarrollo porque teníamos una API SOAP funcional y con estado heredada que estábamos reemplazando (la API heredada en sí misma tampoco tenía un nombre acordado y significativo, por lo que no nos atrapamos demasiado en los nombres )

Ahora este proyecto solo tiene una API que simplemente se llama the <project> API. Cuando finalmente lo reemplacemos, la nueva API simplemente se conocerá como the new <project> API.

Darle un nombre interno sofisticado y descriptivo casi no tiene sentido a menos que tenga tantas API que necesite diferenciar este del resto (en cuyo caso, probablemente también debería cambiar el nombre de todos los demás).

Puede llamarlo una API web . Es un término muy amplio, pero puede evitar dudas sobre el significado de otras definiciones de tipo de API. El término es menos técnico y preciso en comparación con alternativas como HTTP API , pero eso podría ser una ventaja cuando se habla con personas no técnicas.

Este término también lo utiliza Leonard Richardson (quien definió el modelo de madurez de Richardson que ya menciona otra respuesta: una medida bien aceptada de cuán cerca está una API de una arquitectura REST). Es lo que obtienes si sueltas la parte "RESTful" de una " API web RESTful ".