On the Eleven Labs blog they're posted a tutorial showing you how to integrate RabbitMQ functionality into your Symfony-based application making use of a few handy tools that do some of the heavy lifting for you and how messages are handled (and what to do when they error).

RabbitMQ is a message broker, allowing to process things asynchronously. There’s already an article written about it, if you’re not familiar with RabbitMQ.

What I’d like to talk to you about is the lifecycle of a message, with error handling. Everything in a few lines of code. Therefore, we’re going to configure a RabbitMQ virtual host, publish a message, consume it and retry publication if any error occurs.

They use the RabbitMQ admin toolkit and Swarrot packages to get the job done. First up is the configuration of the tools, creating a default_vhost.yml file defining a queue and setting up the exchanges and parameters for the default route ("/"). They show an example of what the RabbitMQ UI looks like with this new exchange up and working and how to get more information about this "default" queue. Next up is the consumption and publication of messages. They include an example app/config/config.yml file that defines some settings the Swarrot library (via the SwarrotBundle) needs to understand the connections, consumers and type of provider to use. Finally he shows the configuration so it all knows how to publish messages and a quick example of PHP code that sends a simple string message to be handled by the RabbitMQ workers. The post ends with a bit more configuration and some examples of how to handle errors in this Swarrot/RabbitMQ Admin Toolkit setup and making use of some middleware to help with message retries and number of attempts.

NetTuts.com finishes off their series covering how to connect your application to Twitter and pull data. In this latest tutorial they show the use of the real-time streams Twitter offers to those needing the most up-to-date and immediate access to tweets via a command-line tool. This tutorial makes use of the Yii PHP framework for it's execution.

While the Twitter REST API is suitable for many applications, if you want immediate updates and access to a broader array of notifications, the Twitter Streaming API is essential. For example, only the streaming API will tell you when another user favorites one of your tweets. Using the Streaming API requires a persistent, keep-alive connection between your web server and Twitter. This type of implementation may be unfamiliar to many PHP developers. As soon as tweets come in, Twitter notifies your server in real time, allowing you to store them into your database without the delay of polling the REST API. Use of the Streaming API is also not subject to Twitter's API rate limits.

They start with a brief description of the Streams functionality and provide a graphic showing the overview of the data flow when you put them to use. They make use of the phirehose library to make the connection (making it almost a two-step method: connect & consume). They walk you through the creation of a Yii command to create the command and set it up for execution. They show you how to integrate it into a larger Yii application, create a migration to store the data and execute the resulting code as a long running command.

Brandon Savage continues his look at using RabbitMQ and PHP together to queue up requests today in this latest post. In this new part of the series, he focuses on the last piece of the puzzle - consuming the requests in the queue. (Parts one and two)

Once you’ve created a RabbitMQ producer, it’s fairly easy to create a consumer. In fact, the only difference is in exactly what commands you’re using. The connection, envelope, channel and queue declarations are the same. While in RabbitMQ you publish to the exchange, you actually do consume a specific queue. As a result, the commands for consuming are part of the AMQPQueue class.

He shows you how to set up the code to sit in the background and wait for a queue request and how to fetch them in a non-blocking way. He finishes off the post with a look at handling success and error conditions (based on the status of message consumption, not the result of the processing).

Ralph Schindler has written up a new post for his blog today looking at APIs and some things to consider when building them. These aren't the web service APIs you're thinking of - this is the interfaces your code uses to talk to it's own parts.

It's important to have a common understanding of the actual problem area. When we talk about names, we are really talking about the API. An API is a particular set of rules and specifications that a developer can follow to access and make use of the services and resources provided by another particular software program, component or library. Put another way, it is an interface between various software pieces and facilitates their interaction, similar to the way the user interface facilitates interaction between humans and computers.

He talks about the two different APIs you're usually building at the same time - a consumption API that is the method others use to consume it and the extension API, how the feature allows others to improve upon it. He shares his own API philosophy and a three tips he's learned along the way to make his APIs more robust:

• Adopt A Common Namespace & Class Naming Scheme
• Avoid Doing Too Much In the Constructor
• Avoid final And private

Brian Swan has a new post to his MSDN blog today about using the OData SDK to consume Azure data (ODP is the Open Data Protocol that's been defined). The OData interfaces is a REST-based service used to grab data from multiple types of data sources.

The SQL Azure OData Service incubation (currently in SQL Azure Labs) provides an OData interface to SQL Azure databases that is hosted by Microsoft. Another way to think about this is that SQL Azure OData Service provides a REST interface to your SQL Azure data.

He shows you how to create the SQL Azure Server, make a SQL Azure database and creating the SQL Azure OData service. Then, with that all set up, you can use this other tutorial to connect your script to this new service.

Phil Sturgeon has posted a new tutorial over on the NETTUTS.com site about working with REST services in CodeIgniter. He shows both sides of things - using REST services and making them.

CodeIgniter is becoming well known for its power as a PHP based web application framework, but it's not often that we see examples of it being used for anything else. Today we'll learn how we can use CodeIgniter to create a RESTful API for your existing web applications, and demonstrate how to interact with your own API or other RESTful web-services, such as Facebook and Twitter.

He has the sample code hosted over on his github account where you can pull down the source and follow along from the beginning. His application is created to be flexible enough for multiple output formats (xml, json, html) and respond correctly to the HTTP request types like GET, POST, PUT, DELETE. On the other side he shows how to consume the services via different methods like file_get_contents and cURL.

Manfred Weber has posted the first part of a quick series looking at pulling information from a PHP-generated SOAP web service inside of a Flash document.

A PHP Pear package to easily create Webservices and WSDL. After several tests with PHP and C# I thought it is time to find a better way in Flash to create backend-driven applications.

He starts with the creation of a simple web service that just returns a string ("Hello!") including what the information page would look like in a browser. Next up is building the Flash side of things - using the serivces.WebService object already in Flash to pull in the info for the service and make the call to the "hello" method.

Manfred Weber has posted the first part of a quick series looking at pulling information from a PHP-generated SOAP web service inside of a Flash document.

A PHP Pear package to easily create Webservices and WSDL. After several tests with PHP and C# I thought it is time to find a better way in Flash to create backend-driven applications.

He starts with the creation of a simple web service that just returns a string ("Hello!") including what the information page would look like in a browser. Next up is building the Flash side of things - using the serivces.WebService object already in Flash to pull in the info for the service and make the call to the "hello" method.