Uncarved

I’ve lately been exploring the value proposition of RESTful APIs to organizations whose technological infrastructures are built upon a collection of legacy software components, customized to communicate with each other by highly tailored middleware software stacks.

That exploration will not unfold in this post, however. It could easily be an entire book unto itself.

Rather, I would like to focus specifically on ideas I’ve had about what a high level object oriented API for interacting with RESTful services might look like, and funnel those thoughts into the design and implementation of a plugin I’m developing for the Symfony framework, called sfRESTClientPlugin.

Audience and Scope

This post assumes at least casual familiarity with Web development. I will explore some general principles of the RESTful interaction paradigm, but only to the extent to which they inform the design direction of the plugin’s API.

Although all the code samples will be in PHP, it is my hope that the exercise will yield material valuable to people working with other software stacks.

Read more…

Public Brainstorm API, PHP, plugin, proposal, REST, sfRESTClientPlugin, Symfony

The Symfony project has recently launched the Symfony Components sub-project and website. Its goal is to produce a collection of standalone libraries for PHP.

Although these libraries were initially born for use in the Symfony MVC framework, the talented developers involved in the project have designed them to avoid any interdependencies with any of the other parts of the overall framework. This effort has resulted in components that may be used individually in any other PHP project without requiring the use of any of the rest of the Symfony framework.

The initial round of components include:

• YAML, a parser that translates data between YAML and native PHP arrays;
• Event Dispatcher, which provides a generic event dispatching framework; and
• Templating, which provides parameterized and scope-isolated templating functionality.

I’ll be keeping a keen eye on this project.

Check it out API, PHP, Symfony, Symfony components

I’ve recently been working on Symfony / Propel projects that deal with particularly large data sets. In such cases, Propel’s documentation recommends a “lazy hydration” approach.

This “lazy hydration” of Propel’s looks like this:

  [#!php]
  // query all the author entities as a Creole ResultSet
  $rs = AuthorPeer::doSelectRS( new Criteria() );

  while( $rs->next() )
  {
    $author = new Author();
    $author->hydrate( $rs );
    echo "{$author->getLastName()}, {$author->getFirstName()}";
  }

The code above does the following:

1. it queries the database for all records in the author table, and loads it into a Creole ResultSet object.
2. enters a loop, iterating over each result (ie, table row) in the ResultSet, and with each of its records, it:
   1. creates a new, empty Author object
   2. hydrates the empty object with the data in the ResultSet‘s current row
   3. writes the author’s last and first name to the output buffer

In this way, only one Author instance is in use at any given time. Each iteration discards the previous instance and creates a new one.

But I hate it — it’s ugly and unwieldy.

This overt use of the ResultSet object is an awkward practice when using an ORM. The primary design goal of ORMs is to allow the developer to work at a higher level of abstraction than SQL queries and database result sets.

So what should it look like? Read more…

Tutorials announcement, development, laziness, PHP, Propel, Symfony