• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (5)

1 localhost commented Permalink

In [code]cart.add(bookID)[/code] --where did you get the cart?!? Wouldn't it be more like:[code] ssb = lookup(ssb); cart = ssb.getCart(cartId); cart.add(bookId); ssb.saveCart(cart);[/code]I would say the proper restful operation would be to [code]put(bookId, cartId)[/code]. Your first step (getting the book to get it's uid) seems wrong, because getting the book would generally be get by Id. Otherwise we are talking search....Anyway, I don't think any services based architecture is object oriented. They really don't match up at all. Just because SOAP has an O in it, doesn't mean it has anything to do with objects. You could be calling a shell script for all you know. They have removed the meaning of the acronym, because, it's not Simple, it's not Objects, it's not a Protocol. I suppose it is Access, but just calling it that would encourage confusion with a certain personal database product. The whole concept of services is invoking functions by the address of where they are hosted. Stateless Session Beans really aren't particularly OO concepts either.It is really the conjunction of object state and object function that forms the basis of OO. The other properties of inheritance, polymorphism, and composition also play a large role. None of that really comes into play when talking about REST, SOAP, and Services.

2 localhost commented Permalink

According to the original definition from Alan Kay, for something to be "Object Oriented", it must have polymorphism, inheritance and encapsulation (http://c2.com/cgi/wiki?ObjectOriented). Does REST have these things?

3 localhost commented Permalink

staticvars and Wayner: Thanks for your comments. Wayner makes some good points about what exactly is object-oriented. REST does not meet this definition; nor, as staticvars points out, does SOAP. So I think that OO may have been a misleading comparison for me to make.Let me try again: I want to model services as an SSB (even if I implement it as a POJO or whatever). An SSB has a domain/service-specific API of tasks like addToCart(cartID, productID). A servlet is stateless like an SSB, but doesn't have a service-specific API. SOAP supports invoking a service-specific API (as described by WSDL). I don't see how you do this with REST--perhaps you can heavily overload POST in some manner, but if so, that seems tricky.So REST may be more like the Web, but seems to be less like the services in my app, and therefore feels less natural to me.

4 localhost commented Permalink

I personally think it's odd to judge "OOness" based on "Session-ness". To me, REST is "OO" in that I send messages to "objects" identified by standardized identifies, and the object either returns a representation of its state (GET) to me, accepts data to process (POST), or accepts data which will represent its next state (PUT) (just to exercise those 3 HTTP methods). IMO, sessions have nothing to do with OO.

5 localhost commented Permalink

Taking a leaf from Ruby on Rails' book:GET http://boo.org/book/1765PUT http://boo.org/book/1765GET http://boo.org/book/1765/titlePOST http://boo.org/cart Id: 89292 Item: http://boo.org/book/1765Is that still REST? I'm getting behind on web services.Finally, remembering you can always write OO code even in languages which don't explicitly support it - it's just a bit more work without the 'syntactic sugar'. I'm told early versions of the C++ compiler basically compiled to C, then ran cc on that.

Add a Comment Add a Comment