« WSDL - Why Services Don't Launch | Main | Compute Power, Is Your Architecture Green? »

Wednesday, January 10, 2007

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83456008969e200d834d64fc153ef

Listed below are links to weblogs that reference A Real eBay Architect Analyzes Part 3:

Comments

Adam Kalsey

The Item resource that's passed back via REST *could* contain only values that are changed.

I'm sure with a little thought we could come up with a scalable way to solve your example via REST, but I'm not terribly familiar with eBay's current web services (last eBay development I did was against Mr. Lister) so I don't understand the use case for CompleteSale exactly. Who normally runs CompleteSale and what changes does it make to a listing?

Duncan Cragg

> as you move from common concepts .. the availability of common formats will decrease.

Yep. No argument there!

> Partitioning is about how you architect your implementation not inherent in the interaction style.

REST isn't a protocol, it's an architectural style based around resources. Partition by those resources. The Web (pretty big) is nicely partitioned that way.

> We have created a massively parallel system that implements SOAP interfaces and has the ability to scale horizontally to incredible levels of parallelism.

I'd love to see more detail about this - as would many others.

> .. if the client passes back an Item (which consists of over 200 state elements) with some state changed, the first task we have to perform is determining the state transition.

Yes - so break things up into micro-resources! That's good practice.

> .. eliminating a clear statement of intent from the information passed by the client, makes it more challenging to partition my architecture.

A given resource in a given partition responds to given state around it with a given set of rules. The intent is clear, the rules compact and probably few in number. I don't see an issue.

Thanks for engaging in this real REST Dialogue - I should get part 4 out quicker than part 3!!

Dan Pritchett

> REST isn't a protocol, it's an architectural style based around resources. Partition by those resources. The Web (pretty big) is nicely partitioned that way.


This is contrasting type partitioning versus functional partitioning. Both work and it remains to be seen which scales better. Either approach supports instance partitioning.

> I'd love to see more detail about this - as would many others.

I think there's a deck out there somewhere that goes through a lot of that!:-)

> Yes - so break things up into micro-resources! That's good practice.

Hmm...now I have my type space growing geometrically so I can expose subparts of my entities? The number of types could degenerate into the number of operations and I fail to see an improved interface for the developer when that happens.

Vadim

Duncan, if you are listening: I wonder if you have actually tried to build a non-trivial system this way. A working example would be most useful, because I'm afraid you are oversimplifying your eBay examples to the point of meaninglessness

Meble

Great article ! Thanks

Leshek

Dan, on microresources, I do not think exposing them grows your types space, you have them anyway, as fields in a bigger resource, you are just exposing them through the interface. So instead of exposing RPC CompleteSale method you exposse .../SaleTransactionState as a resource, I don't think it is a big gain or lose.

Frankly with REST much remains the same. All what you do is put OO on steroids and you have ROA, where some of the functions become resources. Where you can still have algorithms exposed through overloaded POST, to be avioded (e.i. if in doubt, create resource, not overload POST), but not forbidden.

The big deal about REST is that it fits into existing infrastructure (yes, caching is in it), and in the fact that you do not need elaborate, version matching runtime on the clients.

Cheers...

The comments to this entry are closed.