¿Práctica incorrecta POST codificada en la URL?

Question

Estoy (solo por diversión) tratando de implementar un servicio web de puntaje alto. Me gustaría que sea compatible con los principios de REST. Quiero poder agregar una nueva puntuación más alta usando los parámetros url como este http://mydomain.com/hs/add&name=John&score=987. De acuerdo con REST esto debe hacerse usando una solicitud POST. Lo que lleva a una solicitud POST vacía con todos los datos contenidos en los parámetros de URL. ¿Esto se consideraría una mala práctica?

Actualización
La seguridad no es una gran preocupación actualmente.

Answer 1

La forma más común de hacerlo sería enviar un POST a http://mydomain.com/hs/add con el contenido:

name=John&score=987 (por simples Los datos urlencoded serían diferentes para, por ejemplo, datos codificados multiparte, el formato del cuerpo de la solicitud POST es arbitrario y está fuera del alcance de las recomendaciones REST, incluso podría ser datos encriptados arbitrarios, como otros han sugerido.

Una solicitud GET para agregar una nueva puntuación más alta no solo sería una violación de los principios REST, sino también una infracción de RFC 2616, que requiere que las solicitudes GET sean idempotentes.

EDITAR

¿Es una mala práctica para pasar los datos en la cadena de consulta y publicar un cuerpo vacío?

Sí. La URL debe describir el recurso que está siendo sometido a la acción descrita por el método HTTP. Por lo tanto, probablemente la mejor opción sería tener http://mydomain.com/hs como una URL y dejar que el cuerpo describa por completo la acción.

La cadena de consulta, posiblemente, podría ser utilizado para calificar más solicitudes sin un cuerpo, por ejemplo .:

http://mydomain.com/hs?period=lastmonth (GET)

Answer 2

Muy mal..el usuario puede manipular el puntaje. Usted debe aplicar algún tipo de cifrado, incluso si es simple, antes de presentar el resultado a través de la cadena de consulta

Answer 3

GET debe ser utilizada en la obtención de datos. Al agregar o manipular datos, siempre debe usar POST.

De esta manera un usuario no podrá:

• accidentalmente ir a la url de nuevo y rinden todos sus datos sucios
• Intencionadamente alterar su base de datos

Answer 4

se utiliza un signo de interrogación antes los parámetros, por lo que sería: http://mydomain.com/hs/add?name=John&score=987. Sin embargo, la idea es que la URL debe ser el nombre del recurso y el método de solicitud debe decidir qué hacer.

Por lo tanto, la URL correcta sería solo http://mydomain.com/hs, y enviaría los parámetros en los datos POST en su lugar. Como es una solicitud POST, agregará datos al recurso.

solicitud

Answer 5

Uso POST para prevenir siguiente situación: troncos-en

• usuario
• navegador Web guarda información de autenticación entre sesión
recibe
• usuario, por ejemplo, un correo electrónico con HTML contiene src etiqueta como < img = 'http://mydomain.com/hs/add?name=John&score=987' .../>
• El cliente de correo intenta descargar la imagen, usa automáticamente las credenciales almacenadas en el navegador web, y agrega o elimina inf ormación desde/hacia su sistema silenciosamente.

Answer 6

No, el uso de los parámetros url en un POST no es una mala práctica en lo que respecta a REST. Este parece ser un enfoque perfectamente válido para mí.

Desde una perspectiva estética que sugeriría un enlace como

POST http://mydomain.com/highscores?name=John&score=987