--- John Goulah <[EMAIL PROTECTED]> wrote: > What are peoples thoughts on using REST not only as > a web service, but also > within the application itself as another layer of > abstraction? I would > assume in this way all the DB related calls would go > through the REST layer, > and this way they can be invoked as services or > locally through the app. Is > this too much overhead since the model itself is a > layer? > > What are the best ways to deal with this from a > security aspect (such as > making sure people dont call some DELETE action on > senstive data)? Is this > handled with authorization or some other such way? > I wouldn't want an > "authorized" user to delete content they aren't > authorized to delete of > course. > > What are some of the patterns people are using to > implement this? Any other > thoughts? > > > Thanks! > John
I've been trying to build an application around this idea but it's not trivial to model all your business interactions in terms of CRUD like behaviors against resources. For me that was the number one issue. For example, I'm designing a tagging system for internal applications at this bank. We are applying tags to several different types of entities, such as calenders, news items and blogs. We want a global tag system for this so we can build feeds for mixed content based on the tag. You'd think it would be very straightforward since tagging is common and examples abound. But when you actually go to design the URI space you have to make a lot of calls which will profoundly affect how a system is used. Things get complex quickly! For example do you let the API update and add tags via a given resource with UPDATE, like: <news> <content>...inline news content</content> <tags> <tag term="cool"/> <tag term="important"/> </news> Or follow the more RESTful: <news> <content>...inline news content</content> <tags> <tag href="/tags/cool"> <tag href="/tags/important"> </news> Or should the content no be inlined: <news> <content href="/stuff/a.html" type="text/html"></content> <content rel="alternative" href="/stuff/a.pdf" type="application/pdf"></content> <tags> <tag href="/tags/cool"> <tag href="/tags/important"> </news> Some examples above are more RESTful, but makes it harder for your API consumers. I'm far from an expert on the matter but I have tried this and found it's not a cure all. I have noticed all the most successful REST and RESTlike APIs have all been for straightforward and simple services. Building an enterprise API on this may not be easy. In general I've been trying to use the Atom API as my exchange and publishing model. For my custom content I try to use RDF and not invent my own XML each time. Or I find something already existing, such as iCal for calendars. The Atom community for this is very active and can give suggestions. However I also try to make everything viewable as JSON as well, which makes it easier to use some of the available Ajax toolkits for building my management forms. Security wise you should stick with the standard HTTP error codes. For example if a user is not permitted to DELETE than that would return a Method not allowed style error. Overhead is of course an issue but since in theory a properly designed REST system would scale massively it should just be a matter of designing your network properly. Sure I've created more questions than I've answered :0 Good luck! --john __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
