in reply to Re: Web services: current best practices for server side?
in thread Web services: current best practices for server side?

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.

  • Comment on Re^2: Web services: current best practices for server side?

Replies are listed 'Best First'.
Re^3: Web services: current best practices for server side?
by mattk (Pilgrim) on Jun 01, 2008 at 18:49 UTC
    - 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.

[reply]

In Section Seekers of Perl Wisdom