Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Web services: current best practices for server side?

by dmorgo (Pilgrim)
on Jun 01, 2008 at 03:55 UTC ( #689501=perlquestion: print w/ replies, xml ) Need Help??
dmorgo has asked for the wisdom of the Perl Monks concerning the following question:

We have an old web application and would like to redo it as a web service, thus decoupling the main Perl implementation from the web presentation implementation. The idea is we can redo the UI in another language (Java seems to be the preference of the boss), but in my mind this exercise is useful even if we stick with Perl. Stripping out the HTML soup that is currently mixed with the code is going to be my job. Oh, joy.

But the part I am actually looking forward to is recasting this as a web service. I'm just having trouble figuring out what the modern best practices for creating web services are. The book Web Services with Perl (O'Reilly) came out six years ago, in 2002. A bit long in the tooth, maybe... is that book still a good reference?

Would prefer to do the API in a RESTful manner. The application is read / write, not just read, so writes will be done with posts. Is SOAP::Lite what I need? Or SOAP::Server? Or should I just skip SOAP altogether? I've used JSON on a project in the past and liked it; can it be part of a web services solution? (Not to say I like this hammer, now let me shape any problem into a nail, but JSON is a lot nicer to work with than, say, XML).

Am I even asking the right questions? Thoughts, anyone?

Comment on Web services: current best practices for server side?
Re: Web services: current best practices for server side?
by friedo (Prior) on Jun 01, 2008 at 04:36 UTC

    REST is a good set of design suggestions for designing web services, but, like anything else, don't get too caught up in adhering to the philosophy. Use the techniques that will work best for the problem you're trying to solve.

    SOAP should be avoided at all costs. It has no redeeming qualities whatsoever and was probably responsible for the Teletubbies. In any case, REST applications tend to be designed more around a "give me this chunk of information" and "put this chunk of information there" concept, whereas SOAP is a bad attempt at doing RPC over XML over HTTP, which probably isn't what you want.

Re: Web services: current best practices for server side?
by dragonchild (Archbishop) on Jun 01, 2008 at 12:36 UTC
    SOAP is a good idea, but a bad implementation. The key, imho, to web services is that you have a defined API. How that API is implemented is less important.

    As for good design ideas, look at what the AJAX people are doing. The really rich AJAX applications are Javascript applications that consume a Web API.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: Web services: current best practices for server side?
by derby (Abbot) on Jun 01, 2008 at 15:23 UTC

    Right now, REST along with JSON are the predominant players in the opensource Web Services stack. To that end, RESTful Web Services is a good book to start with. That being said, as friedo pointed out, REST is not the be all, end all of Web Services.

    Here are some of the pro's of of using REST/JSON:

    • integrates well with AJAX
    • JSON more perlish than XML
    • CRUD maps nicely into the HTTP verbs

    And here are some of the cons:

    • badly designed services can put a huge load on your server (AJAX gone wild).
    • Error handling hard to map well into HTTP response codes
    • PUT and DELETE not supported by all servers
    • POST/PUT tends to be in flux as to which is a CREATE and which is UPDATE (for me, POST is an UPDATE and PUT is a CREATE, but apparently I'm in the minority).

    That all being said, REST/JSON/AJAX has been a refreshing approach to building webapps for me.

    -derby
      Thanks all for the replies.

      About PUT and DELETE server support, we're using Apache2. Do you know if that's on the bad list?

      Assuming I fashion a system using REST/JSON/AJAX, how big of a problem is it if consumers of the API say they would prefer XML? There are at least two solutions:

      1) Give them XML, even though the core of the system uses JSON - how easy is this in a R/J/A solution, can it be just like adding another view in an MVC application?

      2) Convince them that JSON is just fine - depends on how good the Java support for dealing with JSON is, and on whether the manager is thick-skulled. If Java support for JSON is not so great, then I have a political problem that may override the technology decision. According to the JSON web site, most languages have great support for JSON, but is this just JSON marketing, or is it true? Personally, I'm already sold on JSON, but I'm wondering what you (anybody) have heard about the difficulty of selling the Java people on it.

        - Apache 2.0 will be fine.

        - Supporting different encoding methods is really easy - just check the client's Accept: header (e.g. text/xml or text/json), or a GET/POST parameter (/path/to/app?format=json), or whatever, and pass your data structure to the appropriate module for serialisation (e.g. JSON or XML::Simple) before returning it to the client.

        - There's java code on json.org that will do it, otherwise XML::Simple is easy to use on the Perl side.

Re: Web services: current best practices for server side?
by alpha (Scribe) on Jun 03, 2008 at 19:49 UTC
    2 words: Catalyst Framework

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://689501]
Approved by friedo
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (17)
As of 2014-10-30 19:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (208 votes), past polls