Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Combining a web application and a REST application under a single URI?

by talexb (Canon)
on Jul 20, 2006 at 20:23 UTC ( #562705=perlmeditation: print w/replies, xml ) Need Help??

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

Replies are listed 'Best First'.
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.

      Yep, exactly.

      For the human-friendly pages with forms on them, and the URIs that handle them, you probably cant 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 cant 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 Id 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 Id have a separate URI space to handle the browser-based editing UI.

      Makeshifts last the longest.

          So Id 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 Id 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."

        Don't add your own header field, use the Accept header. That's what it's for.

      Thanks, and for those following along at home, that's section 14.1 of the HTTP 1.1 specification. Select 'text/xml' and we're off to the races (and I may add application/xml as well).

      Alex / talexb / Toronto

      "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

        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.
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.

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://562705]
Approved by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (6)
As of 2020-01-23 19:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?