Sorry to go on a tangent defending Java, but I think you also missed that Java also has a well defined memory model to go along with the synchronized keyword and threading API. Furthermore, Java has been going strong for 15 years now and any web based Java applications are multi-threaded and concurrent. This idea that this “multi-core revolution” is going to change anything is a complete utter myth. People have been running Java (and other languages) on 2, 4, 8, 16, 32, and 64 cpus machines for a long time now very successfully. No, the REAL revolution will be the I/O one when SSD drives become cheap and our I/O speeds go up 10, 100, 1000 times and the line between RAM and persistent storage becomes very very blurry.

@Steve:

Although there are no frameworks out there that hide hypermedia(links) in the language, the pieces are out there to make this a reality. For example, tools like Hibernate have all the metadata and hooks available to automatically insert the links to a marshalled document. Tools like Flex have cool features like automatically versioned objects. When you send them across the wire as a DTO, you automatically get change-set information. If somebody starts combining the ideas in all these frameworks we could get there.

Also, Steve, I wish you would curb your comments about annotations. I get your point, that just slapping @WebService on a Java interface is gay, but one may think you are against annotations in general. For instance, I think the JAX-RS specification is doing some cool work on providing annotations for REST and shows some of the true powers of annotations.

As for this elitism, I agree with Steve J. 10% of developers do 90% of the work. I’m currently lucky because open source provides a nice litmus test for incoming employees and this ratio is much more even, but if I ever had to go back to a traditional company, I’d probably focus on hiring very few and firing the 90%.

There is no guarantee that the Anonymous in the last post and the one prior is the same person.

I do multiple GETs and different representations are returned, however the Last-Modified entity header remains unchanged.

Goodnight.

Cheers,

Zubin.

apparently too sexy for your mind:

ooooo! wow!!! soooo sexy .. I am getting a !@@!# just thinking about it ….

Although you started off with an idiotic comment like the one above, you got better later .. the quote by steve jones corrects things a little …

thanks for that .. I guess you could say it the way you said it .. but people like me won’t understand it ..

you assume everybody using RESTian architectures has a Squid Cache

when did I say that ???

the whole point of putting stuff like this into the goddamn protocol is that it makes it uniform … and if it is so uniform , then you can ask the network stack take care of it … the network stack is on your computer too … that is a major point of fielding’s thesis “Best performance of network based archs is by those who don’t use networks” (or words to those effect .. i really shouldn’t use the quotes )

I have no intention of discussing this further with you on Vinoski’s blog, especially since you have your skirt on. ;)

cos we soooo care!?!!?

I am going to quote Steve Jones, since my English is apparently too sexy for your mind:

“Fine grained interactions across a network are a bad thing(tm) and as REST encourages traversal from resource to resource (which can be pretty fine grained things) then it means that a greater degree of network traffic is likely, add in the GET first before POST and it increases further.

Now add in the “GET idempotent” thing and you can easily imagine people who will map the resource client side with each request hitting the server, after all there is no reason (beyond common sense) not to.

My point is that muppetism in REST will be worse than muppetism in RPC.”

Additionally, you assume everybody using RESTian architectures has a Squid Cache or Content Delivery Network like Akamai in the middle to field repeat requests. Additionally, you assume that because content is cached, it doesn’t have a network cost.

Thousands of clients making indiscriminate requests will potentially cause saturation on the network. If you don’t like the word network saturation, I’ll replace it with “cost” and make you feel better.

Caching reduces network traffic and latency – it does not eliminate it. Also – please define “caching” – Browser? Gateway? Proxy?

I have no intention of discussing this further with you on Vinoski’s blog, especially since you have your skirt on. ;)

Find me on GTalk/Jabber.

Cheers,

Zubin.

But manipulating it is still a pain. So rather than making a lot of finer grained calls and then parsing the DOMs (or whatever the return might be) which becomes a chore, they revert to doing it once in a coarse grained call:

Wow! that must be the worst argument ever!

So tomorrow , when we get better toolkits with REST , REST would become wrong too ?? cos parsing the DOM won’t be a pain …
as a side point , if the WS returns a XML you have to parse it .. how does it matter if you are using WS-* or REST ? By your argument, the people using WS-* would use the network at the minimum cos parsing WS-shit is a pain.

a quick hint on what someone might actually do

/hogs/1 or /hogs.top3 cos you usually need only those numbers.

/processes/hogs would probably only return a list of links (to say /hogs/1 , /hogs/2) with possibly the % usage of each process.

Either you are talking through your HAT or you aren’t able to transfer what you mean into words ….

Turning to Zubin …

Anonymous chap or chapette

Dude either say chap or say chapette … “chap/chapette” is the worst thing to say :O :O

did after reading all the REST media was to break it down into fine grained calls.

The good news is that even if this occurs and people get burned initially, the solution is fairly obvious once you have a think. Although actually the time taken to actually translating that thought to reality can vary.

What the hell are you talking about!?!?

If you actually read Tolkov’s anti-patterns … he just mentions caching with the very apparent point that you don’t need to care about it … it should ideally be all handled by the network stack / squid server / whatever. The only thing I can imagine the client doing is checking the value that tells it how long the representation is fresh for .. but that could also be done by the stack.

mention the risk of over granulation resulting in saturation.

hehehe .. I am really scared asking you … but what does this mean ? over granulation “- I might be able to wrap my head around , but whats saturation ??