The market for books about mashups has become fairly crowded over the past few years but none have really enticed me as from a casual look most seem more interested in following the trend than offering solid information. Thankfully PHP Web 2.0 Mashup Projects manages to slide in a good number of practical programming tips as it works its way through a variety of services.

The book dedicates the majority of each chapter to more general concerns than just interfacing with the system in the chapter’s title. So Chapter 2—”Buy It On Amazon”—spends most of its time exploring XML-RPC and REST approaches and building tools to work with those different styles of interface. Similarly the next chapter spends most of its time introducing WSDL, XML Schema and SOAP before showing how they can be used with Microsoft Live Search.

In fact, that chapter may be one of the best introductions I’ve seen for developers who need to quickly grasp the basics of WSDL and SOAP, a topic that can far too easily get bogged down in complexity that isn’t needed for basic usage. With the WS-* stack quickly and for good reason going out of fashion hopefully most developers won’t have to spend much time with it, but a simple overview is still very handy.

I was intrigued to see the final chapter diving into use of RDF with the RAP toolkit. Like the SOAP section, this managed to boil the basics of RDF down very well and should help most moderately experienced PHP developers to get up to speed quickly.

Aside from a closing section on race conditions, not much time is given to handling interruptions in service from third-party services and in a book focussed on mashups that’s disappointing, particularly as the number of services, and so the range of fallback options, is increasing. Some of the examples are likely to fail if services time out and it would be good to spend some time on helping developers avoid that.

Reading the book as someone who has mostly left the PHP fold for pastures new was a reminder of how easy tools like hpricot make life for screen scrapers, but also that good structure can emerge in PHP code and that the SOAP tools are actually quite good for simple uses. The book is unlikely to appeal to those who don’t do much work with PHP, but if you’re a PHP developer and want to dive into mashups and web services for the first time, it’s worth a look.

Disclaimer: I was sent a copy of this book for review by the publisher, and offered another in return for a timely review. You can find it at packt, amazon US, amazon UK and all sorts of other places.

Recommend this post:

I’m travelling at the moment, so posting has slowed down after three weeks of daily updates. Nevertheless I’ve just about managed to keep up with my newsreader and was pleased to see that some attention has been going into the JSON support in ActiveResource.

Previously parsing JSON that couldn’t be easily handled by the YAML parser was a bit of a pain. Now it’s simply a case of calling:

ActiveSupport::JSON.decode(json_string)

And the JSON param_parser I referenced in my “Versatile RESTful APIs Beyond XML” article no longer needs extra help. It’s simply:

ActionController::Base.param_parsers[Mime::JSON] = Proc.new do |data|
  ActiveSupport::JSON.decode(post)
end

Recommend this post:

An article I wrote has just been published over at InfoQ. It’s called Versatile RESTful APIs Beyond XML and shows how easy it can be to extend Rails’ RESTful behaviour to input and output resources not only as XML but also as JSON and Microformatted HTML.

The article builds on some posts on this blog, such as Intercepting Microformats In Rails Input, but offers a bit more context. The timing of the article fits nicely with a post on the microformats-rest list about Rails, REST and microformats, so hopefully we’ll see more discussion of these concepts over the coming weeks.

Recommend this post:

One feature of recent releases of Rails I hadn’t spotted before is the ability to define your own parameter parsing based on content type. I’m working on an application that will employ a RESTful API and that I hope will take its input in either standard http parameters, microformatted HTML, XML or JSON.

I don’t really want to have to write custom code within the controllers to interpret the input based on content type, so I started looking for how rails parses XML input and came across the following in the actionpack changelog:

    # Assign a new param parser to a new content type
    ActionController::Base.param_parsers['application/atom+xml'] = Proc.new do |data| 
      node = REXML::Document.new(post) 
     { node.root.name => node.root }
    end
 
    # Assign the default XmlSimple to a new content type
    ActionController::Base.param_parsers['application/backpack+xml'] = :xml_simple

Looking at the actual source code it appears it’s actually being implemented slightly differently, with the Mime::Type object being used as the key, rather than the text content type. Since the json content type is already defined (with a reference to the object in Mime::JSON), JSON can (usually) be parsed as YAML, and the :yaml symbol is a shortcut to a YAML parser, handling it transparently is almost as simple as adding:

ActionController::Base.param_parsers[Mime::JSON] = :yaml

or if we wanted to be a bit more explicit:

ActionController::Base.param_parsers[Mime::JSON] = Proc.new do |data| 
	YAML::load(data) 
end

to environment.rb. Building these APIs is even easier than I’d thought!

Recommend this post: