[Catalyst] using REST within the app

John Napiorkowski jjn1056 at yahoo.com
Thu May 24 17:03:34 GMT 2007


--- John Goulah <jgoulah at gmail.com> 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 



More information about the Catalyst mailing list