Entonces, estábamos comenzando un nuevo proyecto desde cero y uno de los desarrolladores sugirió por qué tener solicitudes de API GET, ya que las API POST son mejores en todos los sentidos. (Al menos cuando se usa un cliente móvil)
Al analizar esto más a fondo, parece que POST puede hacer todo lo que GET puede hacer y puede hacerlo mejor:
Entonces, ¿hay una sola razón para tener una API GET? (Esto solo se usará desde un cliente móvil, por lo que el almacenamiento en caché específico del navegador no nos afecta)
¿Alguna vez es necesario tener una API de solicitud GET ya que POST es mejor en todos los sentidos?
En general, sí. En sus circunstancias específicas, tal vez no.
GET y POST son tokens de método .
El token del método de solicitud es la fuente principal de la semántica de solicitud.
Son una forma de metadatos incluidos en la solicitud http para que los componentes de propósito general puedan conocer la semántica de la solicitud y contribuir de manera constructiva.
POST es, en cierto sentido, el método comodín: puede significar cualquier cosa . Pero una de las consecuencias de esto es que, debido a que el método tiene una semántica sin restricciones, los componentes de propósito general no pueden hacer nada útil más que pasar la solicitud.
GET , sin embargo, tiene una semántica segura (que incluye la semántica idempotente ). Debido a que la solicitud es idempotente, los componentes de propósito general saben que pueden reenviar una solicitud GET cuando el servidor no responde (es decir, los mensajes se pierden en un transporte no confiable); los componentes de propósito general pueden saber que las representaciones del recurso se pueden obtener previamente, lo que reduce la latencia percibida.
Anteriormente descartó el almacenamiento en caché como una preocupación, pero es posible que desee repensar eso: la restricción de caché es un elemento importante que ayudó a la web a dominar el mundo.
Reducir todo a POST reduce HTTP de una aplicación para transferir documentos a través de una red a un transporte tonto.
El uso de HTTP para el transporte no es necesariamente incorrecto: el Protocolo simple de acceso a objetos ( SOAP ) funciona de esa manera, al igual que gRPC . Todavía recibe autorización y solicitudes condicionales; características de HTTP que, de lo contrario, podría necesitar implementar las suyas propias.
No estás haciendo REST en ese momento, pero está bien; no todo el mundo tiene que hacerlo.
Eso no quiere decir que creo que todos deberían diseñar sus propios sistemas de acuerdo con el estilo arquitectónico REST. REST está diseñado para aplicaciones basadas en red de larga duración que abarcan varias organizaciones. Si no ve la necesidad de las restricciones, entonces no las use. ( Campo, 2008 )