As so many others, I've fallen in love with the REST mentality as it
seems to embrace a simpler and more flexible model compared to
previous RPC webservice approaches. However, resource design
(especially mapping legacy database tables) remains a massive
undertaking full of compromises and impurities, where assumptions and
hidden context keeps seeping in.
Alas, it doesn't take long for one to wish/require a more powerful
projection model. Looking around, this is indeed manifested in
Microsofts external Azure API (Odata), Google's internal API's (Gdata)
and Yahoo! Social API.
In avoiding the projection problem[1], it's thus tempting to bypass
Java all together and try to map a REST API to some SQL[2] subset.
This would get rid of the OO vs. E/R impedance mismatch, support the
web tier directly (i.e. GWT) as well as offer significant advantages
in B2B scenarios. You would never need to create a webservice, you
would simply setup permissions for a given user and hand her an
endpoint. Exposing canonical REST resources would be a simple matter
of mapping to this extended[3] REST query. Hell, by walking the
resource graph from he root, a dynamic (user role specific) WADL could
be generated.
Am I being naive in the above? Would the security concerns be too
great? Are there other impedance mismatches I haven't though about
yet? Comments appreciated. :)
/Casper
[1] Hard/verbose to model type-safe projections in a language like
Java. WIth Jersey/JAX-RS one has to construct parallel shadow
hierarchies, depending on the resource or how much from an entity is
needed.
[2] Assuming of course that authorization is taken care of at this
level i.e. Oracle's VPD or similar.
[3] I have been successfully experimenting with a domain specific
extended REST query for charts, on the form:
.../chart/{
title:House environment
width:800,
height:600,
scales:[
{
title:Centigrades
plots:[
{meterno:2649,reg:temperature},
{meterno:2649,reg:dewpoint}
]
},
{
title:Humidity
plots:[
{meterno:2650,reg:humidity}
]
}
]
}.png
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
