2011-08-19 19 views
6

¿No sería prudente utilizar varios caracteres de puntuación en una ruta URL HTTP? Estoy en proceso de definir URL de recursos para una API. Estas URL de recursos deberán ser accedidas, almacenadas y transmitidas por una amplia variedad de clientes y middleware, por lo que es importante que no contengan caracteres que puedan causar problemas.Práctica recomendada para delimitadores en la ruta HTTP URL

RFC 3986, section 2.2. "Reserved Characters" especifica los siguientes caracteres como sub-delims: $ & '() * +,; =

¿Alguno de éstos para su uso ilegal arbitraria en las rutas de URL en el esquema HTTP?

Incluso si son legales de acuerdo con las normas, ¿tiene alguna de estas posibilidades altas de causar problemas de interoperabilidad en el mundo real debido a un software no conforme?

¿Existen sub-requisitos específicos que haya utilizado previamente sin problemas en una API ampliamente implementada (esto proporcionaría evidencia de que los que utilizó son seguros)?

La motivación es que tenemos que delimitar los pares clave-valor que no tienen semántica jerárquica. Estamos considerando hacer esto: http://doriantaylor.com/policy/http-url-path-parameter-syntax. Sin embargo, si es probable que esto sea un problema, nos limitaremos a hacer http://example.com/key1/value1/key2/value2

gracias

+0

Me gustaría ir con el esquema de Dorian Taylor hasta que se rompa algo, y luego agregar '/ key/value/key/value' como _alternative_ pero mantener el anterior funcionando para la compatibilidad. – zwol

Respuesta

0

Sea cual sea el camino que tomes, estar seguro de ello; cambiar las API puede ser problemático, incluso con una versión especificada. Es una mala idea para tener varias ubicaciones para el mismo recurso; debe haber una ubicación canónica. Si bien en teoría puede usar un redireccionamiento HTTP 301, si le preocupa la compatibilidad, es mejor evitarlo.

El esquema del conjunto Dorian Taylor parece sensato (y completamente legal) y no debe dar ningún problema de compatibilidad con ningún sistema (o cualquiera que no tenga muchos fallos).

Si la URL debe ser utilizado como un parámetro en una nueva dirección URL de la barra inclinada y es igual tendrá que ser percent encoded, pero eso es cierto tanto para una cadena de consulta estándar (?&=) y su alternativa propuesta, así como la :// si el protocolo está incluido. Obviamente, si desea utilizar ;,= en sus valores, deberá codificarlos.

El único problema posible que puedo ver es si sus URL se almacenan en un archivo CSV, pero las bibliotecas CSV son comunes y la mención de caracteres especiales está bien definida.

Cuestiones relacionadas