Sure, Per. But managing versions will also complicate things. That is because we need to support clients. When in REST clients are part of the system and share the decoupling of servers, then clients will change with us or may not even need to change. In this case, version is not required.
Thanks for your comment!

Thanks Jose! This is the common sense we need to make "common" to all agilistas :D

Yes, Mike.
Sorry, It may be confusing the difference I made about Poker and BlackJack.
I assume BJ is just between the dealer and me. Of course, there are people that uses the exposed card from other players, plus the cards already played to decide, but let's assume we work without that info. Just the dealer and me.

That is a situation where there is a shared deck, but my state (the player state) is personal. The system state (which players have which cards from a deck) is different, and it is not the application state per se. See, each game is an app instance, and that game has states it goes through.

There may be many dealers. Each of them using the same deck. Some dealers may be at break. That is the dealers state, not the app state.

In Poker, you have a game, and app, that is played by multiple players. The tricky part here is that the app is not just a game between me and the dealer, but all other players too. The app state here is more complex, as each other player hand is part of my state. How to image that? Well, each player has an app instance! Yes, my actual app handling drives me winning or leaving the game earlier. If we have 5 players, we have 5 app instances. For the dealer, there is just one system state.

To get out of the gaming world. In an online airline ticket system, at any moment in time, you can have 1000 users connected. Some are just reading the offers. Some are selecting the destination and such. Some more are browsing the option, some others are confirming and entering Credit card info. Some other are canceling the travel.
So, we have many states. There is one app instance per user, and each of them is in a different state.

Actually, Mike, the question goes down to: What is the app?
Is it the dealer system? Or is it a game?
If each player playing one game is seen as one app, and you have multiple instances of that app going on, the you have many app states, but from the POV of a player, it is just one.

So, it is a matter of POV. From the dealer, there are many games going on, and there is just one state of all games at a particular time. From the player POV, there is just one app going on, although it is just a part of something bigger.

The situation get complicated if you want to implement Pocker. There, your knowledge of the others hands are tricky.

Hi Yaron.
Yes, you are right, but the issue is not about consuming the service, it is about the concept and implementation of it. Can you imagine that UI? HOw is it presented to the user? If it is a direct map to the service interface, it is a form the user fills and sends, and waits for a response. RPC. The UI may be totally different if the consumption is more business oriented, like you going on to a bank to request a loan, or to a supermarket picking up groceries, or to a training to learn something. The interactions are far more complex, dynamic, than just fill out a form, send and wait.

Now, RPC affects much more than just governance. That is conceptual. In implementation, RPC causes performance problems due to the illusion of local calls, the cost of serialization, the impedance mismatch you have when working with different platforms, etc. Studies we did show RPC is not as scalable as messaging, also it is almost a rule that composing and reuse has not been as successful using RPC.
I'm not against it, but it may not the be the appropriate tool for that job at hand.

Sure!
It has been a regular practice to design interfaces using the incorrect domain. Many times I have seen users struggling to understand the idea of tables, records and even identifiers (primary keys), when they never use those concepts in their work. Those are concepts from the database world, not from accounting nor medicine nor banking. The idea of an object, with a method that we should invoke, plus the idea of the complexity of that call when the object is not here but remote, is not a concept from accounting nor medicine nor banking.

See the idea? consuming services should be about understanding the business concept, the business contract and the data and processes that consumption requires, not about parameters, calls and proxies.
Could that have an impact on the actual promises of governance? Well, if the tools offer you data on delays, need for more instances, serialization problems, non-responding services, and such, you get IT governance, not business one. You will always require an IT person there.

Hello Patel.
Camel is actually used in very important frameworks. Still, that is a set of patterns implemented in Java (of one the books I have in my bookshelf :D ). Not sure if you want me to talk about the patterns, what Camel means in all that I mention, or if the patterns are actually a solution for the DOS tools are lacking. In that last case, I usually take Camel as a lower level support for what you see in my post. It is not the solution, but may be the base to construct.

Hello Fred.
Actually, it is certainly true that H.A.T.E.O.A.S is something not as clear. That is one constrain whose aim is to achieve the also famous Uniform Interface. Now, that pattern can be implemented in several different ways, for REST particular case, it was done using four interface constraints: identification of resources, manipulation of resources through representations, self-descriptive messages and our friend, hypermedia as the engine of application state. That last one is more aimed to provide support for large-grain hypermedia data transfer. In other words, it is not for APIs!

Now, the fourth constrain is related, but not necessarily is, HTTP. Not how subtle: HTTP is for hypertext, and the restriction is for hypermedia. The issues you mention, which I agree totally, are about the use, misuse and abuse of HTTP operations. They may be to achieve HATEOAS in HTTP, but they are not HATEOAS. You may be even using HTTP operation correctly, but failing to achieve the Uniform Interface.

Difficult, you bet.

Gracias por el soporte.
El derecho al berreo es sagrado. Sin embargo, no siempre se lucha por lo correcto. He visto jóvenes luchar con piedras contra la policía creyendo que es lo justo, creyendo que los policías son malos, cuando estos trataban de salvar una vida. Hay miles de ejemplos.
Esperemos que los convencidos hoy, se den cuenta mañana, ojala no muy tarde.

Hello, jdubray.
Totally agree. I actually like very much your wording :D!

I'm not trying to convince you that REST examples exists. Actually, I'm much of a theorist myself and I can tell you the web itself is architectured using REST style. People think that putting things on the web will make them automatically RESTfull. They are wrong.

Still, the REST restrictions may help when developing real applications. So, let's not throw away the idea, only the wrong implementations.

Cheers!

William Martinez Pomares
Architect Thoughts