rest - ¿Cuál es la forma "Restful" de controlar un servidor?
Tengo un punto final REST para crear una configuración de aplicación como tal
POST /applications
Con cuerpo
{
"appName" : "my-new-app"
}
Me devuelve una configuración de aplicación recién creada:
{
"appName": "my-new-app",
"appId": "2ed17ff700664dad9bb32e400d39dc68",
"apiKey": "a$XVDH9F3Ix4lx2LdxeJ4ZOe7H.bw/Me5qAmaIGF.95lUgkerfTG7NW",
"masterKey": "a$XVDH9F3Ix4lx2LdxeJ4ZOeSZLR1hVSXk2We/DqQahyOFFY6nOfbHS",
"dateCreated": "2021-03-28T11:00:07.340+00:00",
"dateUpdated": "2021-03-28T11:00:07.340+00:00"
}
Nota: Las claves se generan automáticamente en el servidor y no se pasan desde el cliente.
Mi pregunta aquí es, ¿cuál es la forma RESTful de ordenar al servidor que restablezca las claves, por ejemplo?
PUT /applications/my-new-app/update_keys no está basado en sustantivos y, por lo tanto, no es relajante, además pasar un comando como parámetro de consulta tampoco parece ser relajante ya que este no es un método GET sino más bien un PUT. (actualización) método.
------------------------------------
Esta es una forma de enviar un comando que sea lo más REST posible:
Punto final:
POST /aplicación/:nombreaplicación/acciones
Ejemplo de carga útil:
{
"actions" : [
{
"action" : "name_of_command",
"arguments" : {
"arg1" : "param1"
}
},
{
"action" : "reset_keys",
"arguments" : {
}
}
]
}
Las acciones serían sustantivos que forman parte del punto final y el servidor procesará las acciones que se envíen (o publiquen) dentro del punto final. Y una serie de acciones sería la más adecuada para permitir el envío de múltiples acciones. Y cada acción que tenga argumentos también sería deseable para acciones futuras que necesitarían argumentos.
5
Hago más o menosLo mismo, pero es RPC disfrazado, ¿verdad?
Stefanov.sm28/03/2021 a las 12:48
Sí, claro, parece RPC, estilo descanso
- quarks28/03/2021 a las 13:00
lol @ RPC, estilo de descanso Solo para mayor claridad, cuando es RPC NO es estilo REST. Ya hay información falsa sobre REST más que suficiente disponible, por favor dejemos de llamar a todoHTTP relacionado automáticamente con REST o RESTish o similares
- Roman Vottner28/03/2021 a las 13:34
Después de todo, REST es CRUD sobre HTTP per se. Intenta alejarte de él y terminarás siendo tímido en el ámbito de RPC.
Stefanov.sm28/03/2021 a las 13:47
1
No, REST en realidad es más como: el servidor enseña todo lo que un cliente necesita saber.o realizar más solicitudes. Piense en un formulario web que enseñe las capacidades de los recursos, así como el URI, el tipo de medio y la operación HTTP a utilizar. Casi todo es un intento de desacoplar a los clientes de los servidores y, en su lugar, acoplarlos a los tipos de medios reales intercambiados
- Roman Vottner28/03/2021 a las 14:52
------------------------------------
¿Cuál es la forma RESTful de ordenar al servidor que restablezca las claves, por ejemplo?
¿Cómo lo harías con un sitio web?
Estarías mirando alguna página web como /www/applications/my-new-app; dentro de los datos o los metadatos encontrará un enlace. Seguir ese enlace te llevaráa una forma; el formulario tendría controles de entrada que describirían qué campos debe proporcionar para enviar el mensaje, además de cualquier campo "oculto". entradas. Cuando hace clic en el botón Enviar, su agente de usuario recopilará sus entradas, construirá a partir de ellas el cuerpo del mensaje apropiado y luego usará los metadatos del formulario para determinar qué método de solicitud y URI usar.
El cliente nunca tiene que adivinar qué URI usar, porque el servidor proporciona enlaces para guiar el camino.
El hipertexto es el corazón de la interfaz uniforme
REST se define por cuatro restricciones de interfaz: identificación de recursos; manipulación de recursos a través de representaciones; mensajes autodescriptivos; y el hipermedia como motor del estado de la aplicación.
Debido a que el servidor proporciona el URI para cadade los enlaces, tiene cierta libertad para elegir qué recurso "maneja" qué mensaje.
Una forma interesante de resolver esto es observar las reglas de HTTP para la invalidación de caché. La versión corta es que las solicitudes inseguras exitosas (PATCH/POST/PUT) invalidan las representaciones del uri de destino.
En otras palabras, aprovechamos la invalidación de caché enviando el comando al recurso que estamos intentando cambiar.
Entonces, suponiendo que la recuperación de la representación de la aplicación se haya producido mediante una solicitud como:
GET /applications/my-new-app HTTP/x.y
Luego le pediríamos al servidor que cambie ese recurso enviando una solicitud con el mismo uri de destino. Algo análogo a:
POST /applications/my-new-app HTTP/x.y
Content-Type: text/plain
Please rotate the keys
Los envíos de formularios en la web suelen ser una representación de pares clave/valor, por lo que sería más probable que se deletrearan.d ser:
POST /applications/my-new-app HTTP/x.y
Content-Type: applications/x-www-form-urlencoded
action=Please%20rotate%20the%20keys
El formulario que describe esta solicitud puede tener una "acción" control de entrada, que acepta texto del cliente, o más probablemente en este caso la acción sería un control oculto con un valor predefinido.
Nota: si tenemos varias acciones que deberían invalidar las representaciones /aplicaciones/mi-nueva-aplicación, probablemente usaríamos POST para todas ellas y resolveríamos la ambigüedad en el servidor según el cuerpo de la solicitud (si nuestro El marco de enrutamiento nos brinda el grado de control que necesitamos, podemos usarlo, pero lo más común sería tener un único controlador POST para cada tipo de contenido y analizar el cuerpo de la solicitud "a mano".
POST tiene muchos propósitos útiles en HTTP, incluido el propósito general de "no vale la pena estandarizar esta acción". -- Campo 2009
PUT /applications/my-new-app/update_keys no está basado en sustantivos y, por lo tanto, no es relajante,
Eso no es cierto: a REST no le importa qué convenciones ortográficas utilice para sus identificadores de recursos. Por ejemplo
https://www.merriam-webster.com/dictionary/get https://www.merriam-webster.com/dictionary/post https://www.merriam-webster.com/dictionary/put https://www.merriam-webster.com/dictionary/updateTodos funcionan bien, como cualquier otro recurso en la web.
Puedes diseñar tu modelo de recursos de manera que la edición del documento update_keys también modifique el documento my-new-app.
La dificultad potencial es que los componentes de propósito general no sabrán lo que está sucediendo. HTTP PUT significa "actualizar la representación del recurso de destino", e inclusoTodos los componentes de propósito general lo saben; el servidor de origen puede modificar otros recursos como consecuencia de los cambios en las "claves de actualización" recurso.
Pero no tenemos un buen lenguaje para comunicar los componentes de propósito general y todos los efectos secundarios que pueden haber ocurrido. Sin algo de magia especial, las copias previamente almacenadas en caché de my-new-app, con las claves originales, sin rotar, quedarán tiradas. Por lo tanto, es posible que el cliente se quede con una copia obsoleta del documento que describe la aplicación.
(Un ejemplo de "algo de magia especial" sería la invalidación de caché vinculada, que permite describir las relaciones de almacenamiento en caché entre recursos mediante enlaces web. Desafortunadamente, LCI no se ha adoptado como estándar y no encontrará el enlace descrito relacionesen el registro de la IANA.)
3
1
Esta es una respuesta bastante larga. En resumen, ¿te refieres a que las acciones/comandos se enviarán de forma similar al envío de un FORMULARIO? ¿Es eso lo que estás diciendo?
- Quemadura de fuego28/03/2021 a las 17:39
¿La versión corta? si.
-VoiceOfUnreason28/03/2021 a las 21:16
@Fireburn En una arquitectura REST se evita el acoplamiento directo a un servidor; en su lugar, se utilizan uno o varios tipos de medios, entendidos tanto por el cliente como por el servidor. En caso de que busque algún tipo de medio que admita formularios, excepto los formularios HTML, puede echar un vistazo a los formularios HAL o ION, ambos tipos de medios basados en JSON
- Roman Vottner29 de marzo de 2021 a las 5:10