Skip to main content

The restless RESTful-ness

One of the things that I love of the software development trait is how fast things change. We are in a never stopping stream of new ideas, changing paradigms; the essence of pure innovation.
However, once in a while we look back to old dusty corners of what we used to do and believe and find out that those old forgotten ideas taken from mistaken were actually right all the time. Such is the case for REST architecture, a pretty old idea that fell into oblivion just to become the new trendy buzzword a couple of decades later.

Just for historical context; REST architecture was created along with the HTTP specification almost 20 years ago. The idea behind REST is to provide access to resources via an URI, each URI returns the resource representation on a different state, part of the data retrieved from each step contains the means (links) to access a different resource's state (sounds pretty familiar when explained in that way, doesn't it). If you haven’t heard of REST until recently that’s probably because the term was not coined until 2000 by Roy Fielding who was part of the team that came up with the HTTP 1.0 and 1.1 specification, cofounder of the Apache HTTP project and board member of Apache Foundation.

REST services have recently been brought back into the trendy stage. I personally believe that this sudden revived attention has happened due to two facts:

  • The ubiquitous presence of JSON in web applications grants to developers a simple data format that is not only JavaScript native but that is also tied to the HTTP protocol which is the vital breath of the web. With that in the picture and the recent (like 10 years recent) hype in SOA applications this seems like a solid option.
  • People are just sick of trying to implement over-complex and verbose SOAP based services ("Simple Object Access Protocol" is more like a sarcastic name for it )  for simple CRUD non-document based applications where tight security is not a CTQ nor is distributed computing and most of them fall into that category.

However with the hype normally comes the confusion. I have seen a lot of applications that claim to be RESTful just because they user JSON  request/responses strings.  Allow me to explain why I don’t agree with that.


REST web services stand over two main principles or rules:

  • Decoupling through SOA
  • Hypertext driven interactions (HATEOAS)

Decoupling through SOA and Hypertext driven interactions


One of the key points of SOA applications in general is to reduce coupling. SOA is intended so that huge applications can be chopped into smaller specialized distributed entities or services that can work together as a whole so that they can be designed, developed, supported, maintained a hosted in a more sustainable and efficient way.
Each of these services can be built with the technology that better fits the specific needs of each one. This services need to provide some way for the clients to know what they can do and how to do it (decoupling).  As SOAP relies WSDL or WADL so REST relies entirely on the hypertext data returned on the responses to client requests. A RESTful service must provide the client with all the means of interaction (URLs or how to build them) in order to comply with de expected decoupling.  If your REST services require for the client to have certain insight of how your application works beyond a basic knowledge of the exposed resources and the initial URI, or if the services are not using the HTTP native methods to interact with the resources exposed then that is some weird RPC with JSON, not RESTful services (I’m not implying that RPC is bad or inferior, but its definitively not REST).

Another critical difference between REST and RPC/SOAP; REST leverages on the already existent CRUD HTTP methods (PUT, POST, GET, DELETE, INFO, TRACE, OPTIONS, HEAD and CONNECT) while RPC/SOAP services define their own interactions (verbs).  RESTful web services also base the entire interaction in the hypertext received as part of the response (hypertext being XML, JSON , YAML or whatever data representation supported by HTTP ), in contrast SOAP is in fact an XML based protocol so it is not tied to HTTP as REST is (This last claim is debatable, though).

SOAP is still the W3C standard king by all means for all related to web services, it’s a robust protocol  (with a ton of features like WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, WS-RemotePortlets… not simple, definitively not simple at all… unless you compare it to CORBA) ideal for B2B interactions and distributed environments. 



For more simple services REST is a simple yet solid option worth trying but must of all worth doing it the correct way.



Popular posts from this blog

Java - Getting the memory size of an object.

Because the way Java language and the way JVMs are implemented, this apparently trivial task is more complex than it may seem specially when compared to C++ where all objects have a size() method. Java memory architecture is built to abstract the developer from direct manipulation of memory so that the developer can focus on more relevant tasks, this comes with a price.

There are 3 basic approaches you can take in order to do this all with their pros and cons:
Memory guess (Heap Size prior object creation - Heap Size after object creation = Object Size)Java Instrumenting QuerySerialization
Memory Guess
This is the simplest approach because of the fact that you have a pretty easy access to the Heap Size via:
Runtime.getRuntime().totalMemory();

The issue with this approach is that you cannot control what is being thrown into the heap at a given time, JVM is shared by a lot of processes that run in a given machine so this is a error prone approach that is not recommended.

Java Instrumenti…

¿Que tienen los cuchillos de obsidiana y el Nearshore en común?

Presentacion
Aparicion en Campus Night Jalisco Nov 2016
Como siempre me gustaría empezar esta noche con una historia, disculpen uds la insistencia, pero esto es lo que los cuenta cuentos hacemos. Al terminar les prometo que la historia es bastante relevante con lo el tema que queremos tratar.
Este es parte de una historia es solo un fragmento plasmado en el Códice Boturini conocido también como la Tira de la Peregrinación que narra la migración de los Chichimecas de su lugar de origen, Aztlán,  hacia su destino final, la tierra prometida de Teoculhuacan.
El viaje inicia como muchos viajes conocidos, con un personaje misterioso y muy poderoso que convence a un grupo de aventureros a embarcarse en una aventura, en ese caso éste personaje no es otro que el mismísimo Huitzilopozchtli, el dios de la guerra, el sol y los sacrificios humanos, nuestro Gandalf mesoamericano. Nuestra historia comienza pasados más de 2 siglos dentro de este viaje tras muchas peripecias y percances los Chichimecas…

Is the World Shrinking?

Humans are a social primates; that’s an evolutive fact that has been around for a while to the point that it is now collective common knowledge. This presents an obvious advantage if you add to the mix the fact that not only we create bonds to other close members of our species but we like to relate with basically any other members that we came across. We have evolved to be nice with each other. This grants us the ability to extend our influence and our inner circle beyond social, cultural and geographical constraints.

This has been an interesting phenomenon that has been studied for quite a long time. We have been tracing our origins with family trees and trying to find out what we fit in the big picture of society. One of those attempts to understand it is the pretty famous 6 degrees of separation (Also known as the Kevin Bacon's degrees of Separation) idea. The basic idea is this; Imagine that every person in the planet is a dot, and every relationship between them are lines t…