Alpha's Manifesto

A black and white figure's thought-hive

Amar al proxy-mo

Desarrollando en localhost, same-origin policy & REST APIs

Proxy Love

Hasta hace un tiempo estuve peleando con un problema particular, que en realidad es algo común. Desarrollando una aplicación en su entorno local, se encuentran con que tienen que interactuar con REST APIs de terceros, pero desde JavaScript no pueden llamadas directamente a este dominio porque el browser les impide hacer estas llamadas. ¿Qué está pasando y cómo resolverlo?

(Read more →)

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 →)

¿Confianza del usuario vs. URLs acortadas?

Desmintiendo si las URLs acortadas afectan o no la confianza del usuario

Hoy voy a dejar un caso de una pregunta abierta, nuevamente, originada en los foros de User Experience. La pregunta es: ¿Los usuarios confían en URLs acortadas?

Siempre se supo, y es un concepto fundamenta del SEO, que las URLs deben ser lo suficientemente amigables como para significar algo que sea relevante al contenido de ese recurso. Por otro lado, la teoría debajo de REST y la web semántica nos indican que las URLs (o URIs) deberían ser identificadores únicos de un recurso en particular, de forma que, de alguna manera, su identificador tendría cierta relación con su contenido.

Sin embargo, y aún así, parece no haber estudios definitivos realizados sobre lo que los usuarios en general opinan. Nosotros hemos experimentado confianza o desconfianza de estas URLs dependiendo de quién vienen, o en dónde las encontramos. Básicamente, dependería del contexto.

Sin embargo, ninguna de las respuestas tiene algún estudio que demuestre la fiabilidad de su fuente, por lo que yo ya comencé una pregunta que pide por ellos, pero veremos qué ocurre. Esta pregunta sigue abierta e invito a los lectores a aportar cualquier información que tengan al respecto.

Soy un zorrinito acortado.

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: Entendiendo REST

Un tiempo atrás tuvimos una lectura que trataba de una visión simple de la arquitectura REST. Sin embargo, hay mucho más por comprender en esta arquitectura.

En este caso me dediqué a leer el artículo de Ivan Zuzak, llamado Why understanding REST is hard and what we should do about it (Por qué comprender REST es difícil y qué deberíamos hacer sobre eso). El artículo es extenso en demasía, pero quisiera dejar alguna suerte de resumen para que no tengan que lidiar completamente con él sin conocimientos previos:

El artículo explica cómo bajo una interfaz simple como REST se esconde una arquitectura muy difícil de modelar. Un sistema que tiene sus puntas desconectadas de a momentos y todavía debe mantener estados puede ser representado con distintos modelos matemáticos, pero ninguno se ajusta a la exactitud. Una vez que se logre modelar y generar una representación formal de esta arquitectura, pueden establecerse estándares que facilitarán el avance. Más que esto, la existencia de un modelo matemático preciso permitirá predecir sus limitaciones y sus capacidades.

Como extra, la especificación de una arquitectura correcta permitirá también concebir buenas prácticas y conceptos de seguridad para la utilización de este tipo de comunicación que de a poco logrará volver a la web semántica.

Soy un zorrinito semántico.