RESTful web services: When to use HTTP PATCH method


HTTP is a very interesting method but just a few application, SOA or Enterprise Integration developers use all of its capabitities. POST and GET among all HTTP Methods are the most used Method followed by PUT. Yet not very used the PATCH method is very useful and it plays a so specific role that it worth understanding its semantics.

In order to better understand HTTP’s PATCH method let’s have a real-world inspired example. The following figure is a simplified version of a integration project that I’ve been working on.

Users  connect to the cloud-based Payroll System in order to do many activivies such as employee data management.  This system holds the “master data” for employees.

Now imagine everytime an employee data is created or edited in the Payroll System we have to send this new/edited data  (the “1” in the figure) to other systems such as a Sales/Remuneration system (the “2” in the figure), a Performance Appraisal System (the “3” in the figure) and so on (the “4” in the figure).

As described in one of my last posts When to use HTTP Post and HTTP PUT, both POST and PUT create or edit a full Resource Representation, i.e., when you have all of its data.

Bringing it to our Payroll example it means we would create a RESTful web service – in our Tibco ESB – based on POST/PUT  method if the Payroll would send not only the edited Employee data but all its data (all attributes). But that was not the case of the Payroll system I was integrating with. The Payroll sends only the edited data, I mean, if a employee move to another apartment in the same building the payroll would send just the Address’ complement without the street name, city, postal code and so on so forth. That’s why HTTP PATCH was created for!

While in a PUT/POST request, the enclosed entity is considered to be a modified version of the resource stored on the
origin server, and the client is requesting that the stored version be replaced. With PATCH, however, the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version.

Therefore, the final result of the RESTful web services created in Tibco ESB for this project was:

  • POST /employee/id:  Creates a employee in the Payroll system;
  • PUT /employee/id: Broadcasts a message  so that all other systems replace a full employee data. Actually, this will only be used in the future in my project and we did not created it;
  • PATCH /employee/id: Broadcasts a message  so that all other systems update just a set of a employee’s data.

That’s all for today. I hope you now are able to make a better decision on when to use POST, PUT and PATCH when designing RESTful web services.

Tchau!

Anúncios

noSQL and SQL databases: Not an exclusive decision


When trying to find real-world noSQL modeling cases to get some inspiration I ran into the NoSQL Data Modeling Techniques from Highly Scalable Blog. After reading the post and its comments I remembered the discussions around one Semantic Web class I attended last year at NCE-UFRJ. During that class we discussed the future of Triple Stores and that maybe OLTP systems would never leave the relational model and start using Triple Stores. Maybe representing data as RDF would be just another way of representing data the way OLAP systems do.

Almost everytime people talk about noSQL database they end up comparing it to SQL database and the relational model. My opinion at the moment is that it’s not an exclusive (XOR) decision. Since everybody say noSQL databases are better in high traffic/load evironments and SQL databases are better in OLTP env (where data change very frequently), we should take advantage of both at the same time. I mean, let’s have a noSQL database be another form of  data representation that is also in relational databases.

I will try to find how Facebook, Foursquare, Twitter etc use noSQL and SQL/Relational databases. If you see any article, presentation or post that talks about how the use such databases types, or if you have used both together please, share it here by posting a comment. It would be better if it shows an end-to-end architecture using both and not just a peace of it, ok?!

Keep in touch!

As 3 visões da Arquitetura Orientada a Serviços


Durante a edição brasileira do SOA Symposium, que aconteceu em Brasília em Maio de 2011, tive o privilégio de assistir a apresentação de um dos maiores especialistas de Integração e Arquitetura Orientada a Services (SOA). Trata-se do Paul Brown, que é autor de vários livros e atualmente é o “Principal Architect” da TIBCO.

Nessa palestra, Brown relembrou uma definição de Arquitetura contida no livro Software Architecture in Practice publicado em 2003, onde uma Arquitetura compreende 3 visões que são as seguintes:

  • Modelo de Processo: Descreve o processo de negócio na visão do usuário, ou seja, todas as atividades e conceitos envolvidos;
  • Padrão de Arquitetura: Mostra quais sistemas estão envolvidos no processo de negócio, seja por eles possuírem dados ou regras de negócio necessários ao processo, e como eles e seus canais de comunicação colaboram para a execução do processo;
  • Mapeamento Processo x Arquitetura: Descreve em quais sistemas cada atividade do processo é executada. Naturalmente ao fazer esse mapeamento acabamos “explodindo”, ou seja, detalhando algumas atividades do processo.
Um exemplo de cada uma dessas 3 visões

O exemplo que daremos trata de uma questão inspirada num caso real da indústria de mídia relacionado a um projeto que eu estou participando: A extração de entidades a partir de conteúdos editorias.

Antes de apresentar os diagramas, vamos entender um pouco sobre a estruturação de conteúdos em Tópicos usando Extração de Entidades. Para isso, pedi uma ajuda a minha amiga Giselle P. Maia que é especialista no assunto:

Com o crescente volume de informações produzidas por empresas jornalísticas e disponibilizadas em seus sites, a organização tradicional de conteúdo por editorias se torna insuficiente.

Daí surge a necessidade de criar meios para que as essas empreasa possam publicar conteúdo
estruturadamente em páginas chamadas “tópicos editoriais”.

Estas páginas são agrupamentos do conteúdo previamente indexado de acordo com
um “tema” especificado. Nesta visão, um conteúdo poderá pertencer a um ou mais “temas”
simultaneamente, mesmo que associado a uma única editoria. Não é a toa que a organização de conteúdos em Tópicos é um primeiro passo à publicação automática de páginas semânticas.

Uma das formas de organizar conteúdo por Tópicos é (i) identificando Entidades (Ex: pessoas, lugares, empresas etc) relacionadas aos conteúdos e (ii) associando aos tópicos certas entidades. Dessa forma, por um lado a empresa fica com a responsabilidades de criar Tópicos e definir as Entidades a eles associados e por outro se estabelece um mecanismo automático de extrair Entidades a partir dos conteúdos produzidos. Assim, bpara ter uma página de um “tópico editorial” será necessário apenas fazer uma pesquisa no estilo “exiba todos os conteúdos que tenham as entidades existentes no tópico em questão”.

Um exemplo de páginas de tópico editorais é o do Estadão sobre o Pacote de Ajuda aos Bancos e a página de Tópicos do New York Times que na verdade só exibe Entidades.

Agora que sabemos um pouquinho sobre Tópicos e Entidades, temos condições de estabelecer e apresentar suas 3 visões. Para tal, vamos considerar apenas parte da Extração de Entidades, ok!?!?

A figura abaixo mostra um Modelo de Processo simplificado para Extração de Entidades do projeto que estou participando.

Modelo de Processo simplificado de uma Extração de Entidades
Modelo de Processo simplificado de uma Extração de Entidades

Diagramas de Modelos de Processos são uma fonte muito rica para a identificação de serviços numa Arquitetura Orientada a Serviços (SOA). No caso do modelo de processo acima, sinalizei em tom avermelhado quais seriam os candidatos a serviços de negócio.

O Padrão de Arquitetura poderia ser o mostrado na figura a seguir. Nele temos apenas 3 sistemas envolvidos: O Sistema Editorial, o Barramento de Serviçõs (ESB) e o Sistema que possui toda a lógica de Extração de Entidades.

Padrão de Arquitetura que poderia ser utilizado para a Extração de Entidades
Padrão de Arquitetura que poderia ser utilizado para a Extração de Entidades

Ao fazer o Mapeamento do Processo na Arquitetura definida acima inevitavelmente nos leva a “explodir” algumas atividades do processo, o que é perfeitamente normal.

Mapeamento do Modelo de Processo de Extração de Entidades na Arquitetura definida
Mapeamento do Modelo de Processo de Extração de Entidades na Arquitetura definida

É importante observar que os diagramas de mapeamento podem evoluir em nível de detalhamento ao longo do projeto.  Isso se torna mais evidente principalmente se você estiver participando de um projeto que utilize um método ágil de gestão.

Arquitetos devem se preocupar com todas as 3 visões

O primeiro motivo por que Arquitetos de TI devem se preocupar com essas 3 visões é por que quanto mais complexos forem os modelos processos ou os padrões arquiteturas que estão sendo tratadas, maior será o número de possibilidades de mapeamento. Tais possibilidades envolvem diferentes formas de comunicação e diferentes definições de responsabilidades.

Outro motivo é por que mesmo que seja escolhido o melhor padrão de arquitetura um mapeamento inadequado pode comprometer o processo não só no aspecto técnico mas também no aspecto funcional impactando os usuários.

O terceiro motivo é por que somente diante de um mapeamento teremos condições de validar a solução proposta. Apenas o modelo de processo ou o padrão de arquitetura não são suficientes para comprovar (tecnicamente ou funcionamento) a viabilidade da solução ou para que os usuários possa validar a proposta final de solução. Dessa forma, as 3 visões são necessárias e se complementam.

Até o próximo post!