Alpha's Manifesto

A black and white figure's thought-hive

Condiciones OR en REST

Aplicando condiciones complejas a requests HTTP REST

To rest or not to rest

Es muy común que en la especificación de condiciones a llamadas GET REST, la inclusión de diferentes parámetros indique una relación AND entre ambas condiciones.

Por ejemplo:

GET /clients?lastName=Smith&firstName=John

En una llamada así, está claro que los recursos que queremos obtener son aquellos que cumplen a la vez con ambas condiciones: tener lastName Smith y tener firstName John.

Ahora, qué pasaría si quisiéramos hacer una búsqueda de recursos en donde nuestro criterio no sea de necesaria inclusión de ambos parámetros. Por ejemplo, qué tal si quisiéramos que nuestros clientes cumplieran con cualquiera de esas dos condiciones? El problema no es la implementación, sino de qué forma podemos mantener la sintaxis de la llamada lo suficientemente limpia como para que tenga un sentido semántico. Cito (sección 3.4): “El componente de query contiene datos no-jerárquicos que, junto con los datos en el componente de path (sección 3.3), sirve para identificar un recurso dentro del ámbito del esquema del URI y autoridad de nomenclatura (si la hubiera).

Quisiera escuchar opiniones al respecto, pero continuemos.

(Read more →)

¿Por qué distintos dominios para recursos estáticos?

La razón detrás de las URLs raras...

Sabemos que el nombre no es más que un nombre y que no importa cuál sea el servidor actual en donde se están alojando los datos, pero parecería que es una práctica común de muchos sitios grandes (léase: Facebook, Twitter, Google, etc.) hacer referencia a muchos de sus recursos en dominios externos. Por ejemplo, las imágenes de Facebook se encuentran alojadas debajo de http://static.ak.fbcdn.net/ y no debajo de http://www.facebook.com/, ni siquiera debajo de http://imgs.facebook.com/. ¿Por qué?

Alguien ya hizo esa pregunta y la respuesta fue nueva para mí: hay una limitación en varios browsers (y hastas donde yo sabía, algunos sistemas operativos) que previene hacer más de dos, tres o cuatro conexiones simultáneas a un mismo hostname. De hecho, es parte de la especificación HTTP 1.1 (parece que cumplir el estándar no siempre está tan bueno, ¿no?). Ahora, si notaron, la limitación es por hostname, ¿por qué entonces utilizar distintos dominios? La razón es evitar cookies que pueden estar yendo y volviendo en cada uno de los pedidos, y para evitar eso, se puede usar un dominio extra que nunca devuelva cookies. De esa forma, sitios grandes como estos se ahorran mucho bandwidth.

UPDATE: Gracias a Exos, que claramente estaba más informado que yo en este tema, las limitaciones exactas son de tres conexiones por cada dominio y cinco para cada IP. Los distintos dominios/subdominios ayudan a utilizar CDNs para distribución de contenido con mayor velocidad. Exos está en desacuerdo (y demuestra por qué, miren los comentarios) con que las cookies sean una gran carga respecto del bandwidth. Entonces el por qué de los dominios vs. subdominios queda en duda, pero suponemos que debe estar relacionado con políticas de administración interna de cada empresa.

Soy un zorrinito performante.

Sálvenos del REST!

RESTful thinking

Someone save us from REST es el título de un curioso artículo de Rob Connery. Lo curioso es que por lo general REST es una buena práctica y es muy popular y deseado en cuanto a la organización semántica de nuestras aplicaciones web (o de los servicios que estas expongan).

La idea de REST es utilizar toda la complejidad que HTTP provee para dar un sentido más semántico a las operaciones que realizamos. De esa forma, pedir una página y enviar información deberían usar verbos distintos, e incluso deberían haber verbos distintos cuando esa información es nueva o se está modificando información existente. Al mismo tiempo, las URIs deberían ser identificadoras de recursos (de ahí su nombre) y no simplemente direcciones web. Ese es un pequeño resumen, pero la historia va mucho más profunda sobre la idea de darle un significado a las operaciones que se realizan en internet.

Rob Connery lo ve como las peleas grammar-nazi que ocurren en la internet. Es verdad lo que dice y pueden que tengan razón, pero realmente no es tan útil, y hay más discusión y confusión que verdad tras todo ello. Su punto de vista es que se están exagerando mucho las posiciones sobre esta discusión y que nadie tiene realmente una posición 100% clara de lo que REST significa, porque no hay un estándar al respecto.

Soy un zorrinito semántico.

Link del día: Nuevos status HTTP

Y la tecnología se mueve más y más rápido y lo que dábamos por conocido vuelve a cambiar. En este caso, se trata de los HTTP Status Codes, en donde ahora hay cuatro nuevos propuestos, en estado de draft por la IETF: Additional HTTP Status Codes. Nada del otro mundo realmente, aquí no se están proponiendo cosas que salieron ayer, pero es curioso ver cómo las cosas que dábamos por sentado también cambian de a poco.

En este caso está agregando status codes para Too Many Requests, Requests Fields too Large, Requires Network Authentication y Precondition Required, por lo que no nos vamos del rango 400 ni del 500. Unas pequeñas adiciones a lo que ya estábamos acostumbrados.

Soy un zorrinito estándar.

Link del día: Notas sobre HTTP Load testing

Hace poquito encontré esta serie de notas que conformaron un artículo sobre HTTP Load Testing. El artículo trata distintos puntos relativos a cómo se ve afectada la calidad del testing, a la vez de distintas técnicas para tener (o para evitar) de forma que los resultados del testing sean lo suficientemente confiables como para significar algo.

Por otro lado, siempre están esos consejos de la experiencia que podemos leer ahí también, y que si bien no tienen mucho sentido en un principio, tras haber hecho caso podemos ver la razón real de por qué se nos aconsejaba eso.

El artículo está muy interesante, incluso si están pensando en aplicarlo a load testing que no necesariamente sea HTTP, yo creo que aplicaría a cualquier tipo de testing cliente-servidor, y también varios de estos conceptos serían útiles para load testing de cualquier tipo de aplicación.

Soy un zorrinito cargado.