tengo una URL en busca de citas para un usuario de esta manera:matriz en GET para una llamada REST
/user/:userId/appointments
¿Cómo debe la url parecerse si quiero obtener citas para varios usuarios?
debería ser:
/appointments?users=1d1,1d2..
Gracias, Chris .
Las colecciones son un recurso por lo que las citas están bien como recurso.
Las colecciones también suelen ofrecer filtros a través de la cadena de consulta, que es esencialmente lo que usuarios = id1, id2 ... es.
Así,
/appointments?users=id1,id2
está bien como un recurso REST filtrada.
/appointments?users=1d1,1d2..
está bien. Es prácticamente la única opción sensata ya que no puedes pasar un cuerpo con un GET.
creo que es una mejor práctica para serializar los parámetros de llamada REST, por lo general por JSON-codificarlos:
/appointments?users=[id1,id2]
o incluso:
/appointments?params={users:[id1,id2]}
Entonces les ONU a codificar en el servidor . Esto le dará más flexibilidad a largo plazo.
¡Asegúrate de urlencode los parámetros también antes de enviarlos!
En lugar de utilizar http GET, use http POST. Y JSON. O XML
Así es como se vería su secuencia de solicitud al servidor.
POST /appointments HTTP/1.0
Content-Type: application/json
Content-Length: (calculated by your utility)
{users: [user:{id:id1}, user:{id:id2}]}
O en XML,
POST /appointments HTTP/1.0
Content-Type: application/json
Content-Length: (calculated by your utility)
<users><user id='id1'/><user id='id2'/></users>
Por supuesto que podría seguir utilizando GET como lo han propuesto, ya que es sin duda más simple.
/appointments?users=1d1,1d2
Lo que significa que tendría que mantener sus estructuras de datos muy simple.
Sin embargo, si su estructura de datos se vuelve más compleja, http GET y sin JSON, su programación y capacidad de reconocer los datos se vuelve muy difícil.
Por lo tanto, a menos que pueda mantener su estructura de datos simple, le insto a adoptar un marco de transferencia de datos. Si sus solicitudes se basan en el navegador, la práctica habitual de la industria es JSON. Si sus solicitudes son servidor-servidor, entonces XML es el marco más conveniente.
jQuery
Si el cliente es un navegador y no está usando GWT, debería considerar el uso RESTO jQuery. Google en servicios RESTful con jQuery.
. No creo que esta sea la forma correcta de hacerlo. Estás OBTENIENDO un recurso que NO PUBLICA uno nuevo. –
No creo que entienda los usos http GET/POST. No se ajustan al significado del diccionario de inglés para esas palabras. POST es cuando intenta GET pero con los argumentos no colocados no en la url sino en la secuencia de io. –
Es muy desconcertante tener a alguien con una comprensión inadecuada del método POST, pero dependiendo del significado del diccionario en inglés, votar por mí. No puede culparme por las decisiones sintácticas tomadas por las personas que decidieron definirlo de esa manera. No mates al mensajero. –
Otra forma de hacerlo, que puede tener sentido según la arquitectura/el marco de trabajo de su servidor, es repetir el mismo argumento una y otra vez. Algo como esto:
/appointments?users=id1&users=id2
En este caso, le recomiendo usar el nombre del parámetro en singular:
/appointments?user=id1&user=id2
Esto es apoyado de forma nativa por marcos como la de Jersey (para Java). Eche un vistazo en this question para más detalles.
? {Usuarios: [id1, id2]} no sigue los convenios de parametros de querystring de? Key1 = val2 & key2 = val2. – bryanmac
¡Buena captura! edición para corregir ... – sgress454
Además, ¿tiene ejemplos de servicios importantes que ofrecen objetos serializados en filtros de cadena de consulta? De lo que he visto más ofrecen filtros simples de opciones delimitadas por comas o formatos de consulta como OData – bryanmac