I have been investigating REST for the last few days, trying to understand how it works, and what it takes to be implemented. I'd like to use it for implementing yet another web application, as I see it as a very efficient way of communicating.
However, I would like my application to do not only the REST part but also the web server part, ideally using the identical URI. So if it's a script talking to the REST interface, just a very basic chunk of XML will get returned, but if it's a browser, then it will get a menu, nice CSS, header, footer and all of the other amenities you normally see on a web page.
- One alternative is to use a modifier on the URI as Perl Monks does: just add displaytype=xml and get the stripped down version.
- Another alternative is to put the REST stuff in a sub-directory, so the URI goes first to /rest and then on to /project/foobar.
- I could also add in my own header field into the request, and just have the handler Do The Right Thing
There may be other approaches .. I'd be interested in hearing from you about any other ideas or thoughts.
Oh, and here's some reading material for those of you interested in REST:
Also, I installed REST::Application -- quite a nice piece of code, and the note I sent to the author got a reply very promptly, always encouraging. It's written for Apache 1.3, and I'm using Apache 2.0, so it didn't work for me. I may just write my own code to disassemble the requests and dispatch them.
Alex / talexb / Toronto
"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds
|
Re: Combining a web application and a REST application under a single URI?
by thraxil (Prior) on Jul 20, 2006 at 23:57 UTC
|
Don't add your own header field, use the Accept header. That's what it's for.
| [reply] |
|
|
Yep, exactly.
For the human-friendly pages with forms on them, and the URIs that handle them, you probably can’t get away with talking to the REST API directly, though. To be usable, the human interface often needs to handle updating multiple resources at once in some fashion, or may have functional aspects that can’t be associated with any particular resource in the system. Trying to build an interface that rigidly follows the resource structure of an app just makes for a mediocre user experience, at best.
So I’d have the bookmarkable friendly URIs be capable of returning both human-friendly and machine-readable representations via Accept, and maybe also have them respond to programmatic access (by PUTting/POSTting with a request body with XML or JSON or something like that), but I’d have a separate URI space to handle the browser-based editing UI.
Makeshifts last the longest.
| [reply] |
|
|
So I’d have the bookmarkable friendly URIs be capable of returning both human-friendly and machine-readable representations via Accept, and maybe also have them respond to programmatic access (by PUTing/POSTing with a request body with XML or JSON or something like that), but I’d have a separate URI space to handle the browser-based editing UI.
My plan is to provide RESTful access via the Accept header types of text/xml and application/xml, and web access (menus, CSS) for application/xhtml+xml and text/html. The problem that I'm trying to solve now is that Firefox uses the following accept header: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5. I guess this means my application will always have to provide HTML of some sort, unless the script asks only for XML, in which case I provide XML, in a "Just the facts, Ma'am" [1] format.
Alex / talexb / Toronto
"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds
1. Obligatory link to Snopes for the pedants in the crowd. The quote is actually "All we want are the facts, ma'am."
| [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
Reminder: Since you are delivering different HTTP responses according to a UA supplied header field, you must add the appropriate Vary header to your HTTP response.
| [reply] |
Re: Combining a web application and a REST application under a single URI?
by Asim (Hermit) on Jul 28, 2006 at 16:57 UTC
|
Have ye considered the Catalyst framework for all of this? There's a somewhat out-of-date Catalyst tutorial that does an app with both HTML and XMLRPC interfaces. Swap in one of the Catalyst::View::REST-style interfaces for XMLRPC, and with some digging, it might be adaptable to your needs. I know you can get the header information in Catalyst fairly easily, and call Private functions within it for your seamless front-end.
Edit: Looks like the Catalyst Cookbook covers XMLRPC, as well, taking ideas and examples from the above link.
Does that sound useful for you?
----Asim, known to some as Woodrow.
| [reply] |
|
|
I tried to wrap my brain around Catalyst, spending about a week reading the docs and trying the examples, then about another week doing the same with DBIx::Class. I also visited the Catalyst and DBIx::Class IRC channels, getting some excellent assistance from our own castaway and Matt S. Trout (mst), among others.
Ultimately, I just wasn't able to 'get' how to use Catalyst or DBIx::Class. That's not necessarily a shortcoming of either package or their respective (overlapping) user communities. In fact, I owe those folks a beer or three for all their help.
I've now had a look at REST::Application and set that aside as well -- it looked very nice, but it ties in with Apache 1.3, something I didn't realize until I started trying to get the examples to work. I'm currently using Apache 2.0, and will probably go with Apache 2.2 since I believe the target OS is FC5. I'm now at the point where I'm probably going to use CGI::Application along with Apache's rewrite engine so that REST style URIs are mapped to CGI equivalents -- the REST URLs will get XML, and the normal URLS will get HTML. My prototyping has developed paralell page templates for the two formats, so I'll use one piece of logic to service the request, then present the results in the appropriate format.
I'll be using CGI::Session for authentication, hopefully by way of CGI::Application::Session, and I'll be using cookies instead of trying to cram session information into URLs.
Alex / talexb / Toronto
"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds
| [reply] |
|
|
