Implementing APIs / returning json/xml data for a request
6 views
Skip to first unread message
Ian Eslick
Sep 9, 2009, 10:44:56 PM9/9/09
to webl...@googlegroups.com
Hi all,
I'm trying to determine the best way to allow a weblocks webapp to
implement a REST style API ala twitterThe problem is that any webapp
request wraps all returned data in an <html tag with header info
embedded. I either need to write some kind of extension in the
weblocks request handler or add another raw dispatch handler to
hunchentoot. Has anyone solved this problem already (providing RSS
feeds, etc?)
Ian
Leslie P. Polzer
Sep 10, 2009, 3:13:22 AM9/10/09
to webl...@googlegroups.com
You can use Hunchentoot's ABORT-REQUEST-HANDLER (I think that's
the name) to send a direct reply from your dispatcher, thus
bypassing the Weblocks request pipeline while still using
Weblocks dispatch.
Leslie
Ian Eslick
Sep 10, 2009, 5:37:27 AM9/10/09
to webl...@googlegroups.com
Ah, excellent. Thank you Leslie.
For posterity... During the dispatch and rendering phases, nothing
happens to the hunchentoot http stream until render-page gets called,
which is after the widget hierarchy is rendered to a string. At any
point in those two phases you can return a string (or stream?)
explicitly via abort-request-handler and have it be pushed out in the
reply with the current reply header settings.
Be sure to set the content type: (setf (hunchentoot:content-type*)
"text/xml")) so the receiving browser does the right thing. I simply
stuck a test into my top level dispatch widget which picks off URLs
based on a root token (e.g. /webapp/api/...) and calls an API handler
that uses the rest of the tokens, the parameters, and the session
authentication object to determine what to return.
Ian
For posterity... During the dispatch and rendering phases, nothing
happens to the hunchentoot http stream until render-page gets called,
which is after the widget hierarchy is rendered to a string. At any
point in those two phases you can return a string (or stream?)
explicitly via abort-request-handler and have it be pushed out in the
reply with the current reply header settings.
Be sure to set the content type: (setf (hunchentoot:content-type*)
"text/xml")) so the receiving browser does the right thing. I simply
stuck a test into my top level dispatch widget which picks off URLs
based on a root token (e.g. /webapp/api/...) and calls an API handler
that uses the rest of the tokens, the parameters, and the session
authentication object to determine what to return.
Ian
Reply all
Reply to author
Forward
0 new messages