DZone - Comments

Of course I am giving an

luxspes — Fri, 14 Nov 2008 22:42:19 -0500

Of course I am giving an example where a URI is constructed and reflects a SQL query, that is want URIs do, they indicate a resource.. URI is Uniform Resource Indicator, it is there to indicate you where is a resource... no? and that is what SQL queries do too, don't they, you write an URI and you get the resource it is pointing to, you write an SQL query and you get the resource it is pointing to. So, why we do not write SQL query like stuff in browsers? Plain luck, plain bad luck, because the guy that invented URIs didnt remember that SQL only needed an small extension to do what URIs do.

If the significance of the HTTP verbs is to do with safety and idempotency then it would I be right to say that:

Safe means a request doesn’t cause any side effects. A safe request just grabs data from a database and display it. Static pages, browsing source code, reading your email online — these are all “safe” requests

Idempotent means that doing the request 10 times has the same effect as doing it once. An idempotent request might create something in a database the first time, but it won’t do it again.

Then:

SELECT: safe and idempotent

DELETE = not safe + idempotent

UPDATE = not safe + not idempotent

INSERT = not safe + not idempotent

So we could say that SQL is missing an operation that is not safe + idempotent, a kind of UPSERT or MERGE operation that can be called many times without risk, if we add that, then SQL becomes RESTful?and if it does not, what is the name of SQL+UPSERT?

You're talking about HTTP

MikeK — Fri, 14 Nov 2008 11:10:09 -0500

You're talking about HTTP specifically, not REST. All you're doing is giving one example where a URI is constructed and reflects a SQL query, why does that mean that every URI is representative in this way? That's an assumption on your part.

The significance of the HTTP verbs is to do with safety and idempotency, rather than 'CRUD':

GET = safe and idempotent

DELETE = not safe + idempotent

PUT = not safe + idempotent

POST = not safe + not idempotent

There's plenty of reading material available for you - Fielding's dissertation is a good start (since that's where REST came from).

Maybe I didn't explaing

luxspes — Fri, 14 Nov 2008 09:32:03 -0500

Maybe I didn't explaing myself I am not saying REST is wrong, I am just saying that this idea of using GET / PUT / POST / it is just too similar to what SQL provides, we could say that GET is SELECT, PUT is INSERT, POST is UPDATE... yes I know they are not exactly the same but they have the same philosophy, why this similarity does not seem to have (buzzword) name? or do you know the name for it?

Also can you explain me why this:

http://company/payrollsystem/employees?salary=5000

is (or is not) so much better than:

select * from company.payrollsystem.employees as e where e.salary=5000?

or why the most exciting thing about something like:

select * from http://company/payrollsystem.employees as e where e.salary=5000?

it is that it is using an uri and not that relational algebra is still the most useful way to manipulate data?

"REST is SQL for XML/Http" -

MikeK — Fri, 14 Nov 2008 09:06:42 -0500

"REST is SQL for XML/Http" - rubbish. Sorry, but that's just plain wrong. For a start, what does XML have to do with anything?

Your claim that it is merely 'new clothes for the old emperor' is based on a lack of understanding at your end. RESTful applications completely change the significance of a URI - In that, unlike RPC, a URI is used to... indicate a resource.. Uniform Resource Indicator.. does that make any sense to you? No? Oh well then, nevermind - you must be right.

This is fundamental change to the way in which a UA interacts with your application; namely that it actually makes proper use of URIs (and the HTTP protocol) instead of just using HTTP as a convenient transport for tunnelling through firewalls. HTTP is not a transport protocol, it's a transfer protocol.

In all seriousness, how much do you actually know about REST?

REST versus SQL? These

bblfish — Fri, 14 Nov 2008 08:31:54 -0500

REST versus SQL? These debates clearly show that what is needed is not more dicsussion but some exploring of real RESTful services that play in the linked data world. Try out the Open Calais service from Reuters, the global news agency.

Well in a way we could say

luxspes — Fri, 14 Nov 2008 07:23:43 -0500

Well in a way we could say that RDMBs serve HyperText: think about it, most non trivial web applications store pretty much all its information in RDBMS, so just because a WebServer transforms it in to XML it suddenly becomes such a different buzword compliant thing? Take a look at Microsoft Astoria, what else its but a thin layer on top of a RDMBS that translates urls in to SQL queries?

And the URL... the URL is just there to name a resource, if you have an url like:

http://company/payrollsystem/employees?salary=5000

what is the advantage of that vs:

select * from company.payrollsystem.employees as e where e.salary=5000?

they both do the job: specify that we want, all the employees with salary of 5000. But what if we want to do a Join? (or many Joins, with Unions, and Exists and other relational stuff) if we use the SQL query we are fine (I would prefer to use a D but that is another story), and if we use an URL? well, then we are in trouble, because AFAIK there is no standard way to deal with this things in URLs. Is SPARQL for that? If that so it is so sad they have chosen a syntax so terribly flawed.

And about REST being for "global, distributed, one with no central point of control [stuff]" that idea certainly looks good in paper, but think about it,if in practical terms SPARQL is using HyperText datasources, that means they do not come indexed, or even in a nice binary optimized format, they are just a huge XML/XHTML file, if we currently have performance issue when we link an Oracle database with an Ms-SqlServer database and try to do a join between a table in one of them an a table if another (oh, and please explain me why that is not global, distributed, with no one central point of control stuff)... Just thinking about the performance hit of a Join in SPARQL makes me think that something is really flawed with that approach...

REST and SOA are like SQL expression and Stored procedure, REST is SQL for XML/Http, and SOA/RPC is stored procedures for XML/Http, but in the end, they are the same thing, they are just new clothes for the old emperor. They are a new, perhaps nice layer on top of already existing technology,but, somehow manage to attract all the hype, and in the process they even find time to say that their way of working is so revolutionary that it makes old technology obsolete, when in reality they are just thin extensions on top of that "old technology" they claim to replace. I guess that is why some times those of us that do not fully get what is so great about REST feel like a REST proponents can seem like...well, fanatics (members of a cult)...

No offence, but you're

MikeK — Thu, 13 Nov 2008 10:01:34 -0500

No offence, but you're coming across a tad pretentious.

I don't really understand the point you're trying to make..

Hi MikeK, No SOA is not a

dibblego — Wed, 12 Nov 2008 17:05:41 -0500

Hi MikeK, No SOA is not a cult and not under my given definition. A cult is made up of members who propagate a non-idea. SOA is a non-idea. It is given unwarranted legitimacy, since it also (like REST) does not exist in a logically consistent form. I've no doubt it looks differently to an observer who lacks rigour in their formal reasoning, but this is aside and one that is uninteresting to argue (it often degenerates quickly yielding no useful conclusion).

It is possible, though I am not necessarily suggesting it, that proponents of SOA may form a cult, but SOA is itself not a cult. As a non-existent concept, it certainly exhibits all the required traits for it to follow.

pointless points are one to

MikeK — Wed, 12 Nov 2008 07:41:35 -0500

pointless points are one to look out for aswell - defensive garbage which contains lots of blind flailing and finger pointing.

Apparently sharing passion and conviction for something makes you part of a cult, does that mean SOA is a cult? I'd say yes, according to Tony's ridiculous definition.

So assuming that baseless and pointless accusation it true, does it actually negate the value of the arguments made in favour of SOA and REST? Clearly not,

It's worth considering how much collusion and misrepresentation is brought to the table by individuals and groups who have invested interests in keeping development methodologies overly complex and drawn out - money, money, money; you have to keep up cash flow and barriers to entry.

"The thing I do not get is

dibblego — Tue, 11 Nov 2008 23:03:41 -0500

"The thing I do not get is why nobody realizes that Rest Is Just Sql Reinvented,"

luxspes, REST is a non-concept. It does not exist in any logically consistent form. It is important to the survival of non-concepts that they be ill-defined and masquerade otherwise. They often perpetuate by repetition of myth with peer reinforcement and pseudo-science. You will no doubt attract the wrath of a cult (or member of) within the REST proponents who will accuse you of making a misrepresentation of REST with the presupposition of your statement. Indeed, cults within the cult war with each other over this definition. Some call it religion. These people are not malicious, but ignorant and scientifically illiterate. You should understand this to resolve your dilemma.

If you can understand why non-concepts exist and how they survive, you will have no problem understanding why nobody realizes...

REST is not 'SQL reinvented'

MikeK — Tue, 11 Nov 2008 10:53:36 -0500

REST is not 'SQL reinvented' - that is utter nonsense. Actually reading the dissertation might help you 'get why nobody has realized this yet'. It is fair to say that the 2 share some similarities, but they are complementary to one another - I fail to see how this is a criticism of any kind, quite the opposite.

Mr Neward, I completely disagree with the final part of your article.

REST could be viewed as just a means to an ends from a technical perspective, but practically speaking - the benefits to business of the RESTful approach outweigh those of any other alternatives, in most cases. Better technical interoperability begets more business interoperation, and this can only be a good thing for SOA.

Why is it wrong to suggest that the 'perfect' SOA adheres to REST principals, particularly when all the evidence seems to support that suggestion?

It is, to some extent, worth making the point that it is not always necessary or appropriate to follow every one of these principals, but also to make the point that careful consideration should be given in making that kind of decision because the opportunity cost of doing so may be large.

Perhaps you could give an example of where RESTful principals require breaking?

yes, there is a very close

bblfish — Tue, 11 Nov 2008 04:59:58 -0500

yes, there is a very close similarity with SQL, and of course some serious innovations. The innovations is of course what is important, otherwise you could just say: what is the point of SQL is that not just so much like say paper card indexing, or COBOL?

The big difference is of course the URL. That is you have a system of distributed data. In a Relational Database (RDB) the data can only be contained and controlled by one organisation, or when multiple organisations are involved a lot of interaction overhead is required. RDF makes it possible to link data in a distributed way across the internet. It also has a query language that is very close to SQL: SPARQL. So yes you are right in many many ways this is very similar to Relational Database. The difference is that what is being worked on is a global, distributed, one with no central point of control.

Now of course you can break REST principles. And a huge number of applications do. They may indeed have many other benefits, such as tying people into your system. But what they don't get are the benefits of REST, which of course is not minor. It is related to metcalf's law, and the benefits one gets by participating in a huge system whose value grows exponentially.

So what readers of this excellent article should be wondering about, is what are the benefits of REST that they may be missing by not following its principles?

Well, SQL is not serving

sduskis — Sat, 08 Nov 2008 18:46:30 -0500

Well, SQL is not serving hypertexts last time I looked at it. ;o)
But more important (and related): There is no equivalent to the URL!

Playing devil's advocate, relational databass do indeed have an equivalent to hypertext: foreign keys.

thanks, this is a clear

fede309 — Sat, 08 Nov 2008 08:36:53 -0500

thanks, this is a clear explanation of the REST pattern!

Well, SQL is not serving

beders — Fri, 07 Nov 2008 21:43:31 -0500

Well, SQL is not serving hypertexts last time I looked at it. ;o)

But more important (and related): There is no equivalent to the URL!