tag:blogger.com,1999:blog-17014496.post1830371060262421234..comments2024-02-20T10:30:44.870+05:30Comments on Could we be looking at it all wrong?: Putting REST to restSaager Mhatrehttp://www.blogger.com/profile/03869587109666583246noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-17014496.post-44847321302385256402008-10-13T10:07:00.000+05:302008-10-13T10:07:00.000+05:30I'm sorry, but I'm completely confused. I believe ...I'm sorry, but I'm completely confused. I believe that REST has very little (if any) to do with <I>implementation</I> of your business logic. It's all about the interface.<BR/>I'll admit my first RESTful service implementation was in RoR (with Restlet clients that we messed up :P), but that has nothing to do with my rant.<BR/>My rant is around the semantics of REST as an integration interface and not about 'fat models and skinny controllers'.or services were fat models fronted by skinny controllers (avg 3 lines per method), but the interfaces of the resources themselves were preposterous. In order to avoid 'chattiness' we ended up creating vague coarse-grained resource verbs that made the client interaction look positively preposterous.<BR/>That's where I'm coming from.Saager Mhatrehttps://www.blogger.com/profile/03869587109666583246noreply@blogger.comtag:blogger.com,1999:blog-17014496.post-78207348674163663442008-10-12T21:38:00.000+05:302008-10-12T21:38:00.000+05:30I think you're missing the point of REST. Once yo...I think you're missing the point of REST. Once your team embraces REST, you stop having those arguments about where stuff lives. <BR/><BR/>It sounds like you're using rails. Once your team embraces REST, you'll never have to learn a completely new strategy that maps to a completely new domain (that is actually suspiciously not that different from the last 5 that you worked with) for how to name controllers and what to put in views.<BR/><BR/>In my opinion, having worked on and built many rails apps, the two most simplifying and helpful guidelines for rails architecture are REST and "fat model, skinny controller". They help stop us as developers from arguing and wasting time thinking about where stuff lives so we can spend time designing our domain layer in our models, because that's what our clients are paying us to do.Jeremy Lightsmithhttps://www.blogger.com/profile/04130044068801660189noreply@blogger.comtag:blogger.com,1999:blog-17014496.post-59177337142090646622008-07-29T10:14:00.000+05:302008-07-29T10:14:00.000+05:30I disagree; although not the biggest, integration ...I disagree; although not the biggest, <B>integration</B> is perhaps one of the most painful bottlenecks to getting something out there. Integration end-points should be intentional, not accidental. If I'm going to put up a service, I'll publish a well defined API using a accepted protocol/standard that fits my model. I may even provide a web simulator for it. But I'm not sure I want to base it on another application protocol; I'm diving further down the stack. I want to leverage the Net, not the Web.<BR/><BR/>The web is, finally, only a document delivery architecture. Overloading that will only cause abstractions to leak, or result in unnatural/faulty abstractions.<BR/><BR/>Besides HTTP is a lousy protocol for application development, unless the system is inherently completely stateless. So-called RESTful services like Google translate and search work, but could be much better.<BR/><BR/>Also, I'd say the IPv4 argument goes somewhat against the grain of your argument. IPv4 (or anything at the transport layer and below) is <B>not</B> human-readable.Saager Mhatrehttps://www.blogger.com/profile/03869587109666583246noreply@blogger.comtag:blogger.com,1999:blog-17014496.post-54077246337972358382008-07-29T01:12:00.000+05:302008-07-29T01:12:00.000+05:30The biggest thing I like about REST is that I can ...The biggest thing I like about REST is that I can look at a Web Service with my browser and understand the result myself. Sure, specifying everything with wsdl has advantages too. But since there's so much stuff out there on the web already in human-readable format, maybe our software has to be able to use that. If we can design services that are discoverable by regular web searchers during regular surfing, we might find that they end up being used more.<BR/><BR/>It's like IPv4: surely we should have abandoned that by now for something better. But there's so much of it out there, and it already works, that you just can't ignore it. You have to try to fit in and do the best you can with it.Johnhttps://www.blogger.com/profile/05474026469862640794noreply@blogger.com