On PHPMaster.com today there's an article with some good suggestions about ways to deprecate parts of an API safely.

Deprecation can happen for various reasons - perhaps an API is no longer useful and has reached its end-of-life, or the refactoring of code to improve its reusability and testability obsoletes particular methods. In this article I'll share with you some key points that you should follow when deprecating APIs so you can continue to grow your code and provide fair warning to those who depend on it.

They break it up into a few different steps:

• Prepare for Refactoring
• Employ the Single Responsibility Principle
• Communicate with your Users
• Remove the Old Code

Lukas Smith has a new post to his site that asks the question "what's needed to REST in Symfony 2?" In it he talks about some of the current issues surrounding REST support in Symfony (bundles) and a "call to arms" to create something better.

I think we already have quite a nice toolchain for REST in Symfony2 with Bundles like FOSRestBundle, JMSSerializerBundle, NelmioApiDocBundle, FSCHateoasBundle and HautelookTemplatedUriBundle. What is great about these Bundles is that they are all nicely integrated with each other. But there are still some limitations which should be addressed.

Some of the still outstanding issues he points out include issues with content-type and routing, dynamic content in the NelmioApi bundle, Behat context testing, JSONP support and more. He suggests gathering together a product backlog of these items and possibly making a kickstarter to fund its development.

On the Etsy "Code as Craft" blog there's a recent post about their move to using the GeoNames service internally rather than the external, third-party API previously in use.

People are passionate about where they live. At Etsy we need to keep track of lots of different locations, such as buyers' billing and shipping addresses and sellers' shop locations. As Etsy continues to expand internationally we wanted to provide better localization and translations for our location place names. We determined that the best way to effect this change was to move from using a closed location API provider to internal services backed by the open GeoNames data set.

The post details some of the steps in the process including the mapping of the current data to the new structure (the script is available on github). They talk about how they mapped their old data over (trial and error sometimes) and the creation of a database of "GeoNameIDs" for each customer in their records. They've also implemented a Lucene/Solr search for improved searching and auto-suggestion based on the user's location.

In this recent post to the Duckout blog, they show you how to hook your PHP-based (and database driven) application into the Google Charting API for chart/graph generation.

I think, whenever we see a chart in a magazine, in books or applications our brain say's to us Yeepie!!! Don't read these stupid texts or tables! Just look at the green or yellow line and hope that they are above the other lines or hope that your opinion is the biggest part of the pie¯. This saves us a lot of work and in my opinion we should concentrate on drawing beautiful colorized pie charts, instead of writing long boring articles. But the question is: ¯How do I draw these beautiful colorized pie charts? The simple answer is: you don't have to, because google will draw them for you and you just have to tell them what to draw via the google charts api.

The sample application is a "breakfast rating" tool that logs the results to a MySQL database via PDO calls. The results are then extracted and formated as JSON to be compatible with the Google Charts API data handling. Some sample Javascript is included showing how to call the Charts API with your data and get back a simple line graphing of the data from the database. You can see the application in action here for reference.

Andrew Podner has posted about the password hashing functionality that's coming with PHP 5.5 - how it will work and some of the benefits of its use.

Recently PHP 5.5 was released into beta, which puts us one step closer to another release of PHP. This week, I thought I would spend a little time explaining a new feature that will be implemented in 5.5 that will hopefully make dealing with passwords easier for developers to grasp and properly implement. I cannot tell you the number of apps, even ones written within the last year or so, that I open up only to find either an md5 hash, or worse, clear text password storage. I keep telling myself that eventually this will come to an end, and people will stop taking the easy way out. Maybe PHP 5.5 will have made it so easy that there is simply no further excuse not to implement solid password hashing.

He includes an example of the four new functions that will come with the hashing functionality: password_get_info, password_hash, password_needs_rehash and password_verify. He includes the parameters that should be included in each call and the details from the call to get the hash's info. If you're not going to be able to move up to PHP 5.5 when it's released, you might consider looking into this compatibility library to have a similar interface and functionality (for 5.3.7 or greater).

In a new post to his site Justin Carmony shares some of his experiences with doing test-driven development (TDD) for a new project he was working on interfacing with the Omniture API. In it he shares six lessons he learned during the work.

At work we use Omniture for our web analytics, and for a long time I've wanted query our Omniture Data to run some internal reports. I discovered that Omniture has a restful reporting api, and after using it for a little bit I decided it would be nice to write a wrapper library for it. Since I had recently taken the PHP Testing Bootcamp from Chris Hartjes, I decided I wanted write it using Test Driven Development and really get my feet wet. I also decided I wanted to make the library compatible with Composer. After the weekend was over, I had an almost finished library that just requires some more work to be done, but I learned a great deal that I thought I'd share.

He's broken the post up into sections, each with their own summary:

• TDD is 90% changing the way to write code, and 10% writing tests
• Understanding Mock Objects is the real key.
• It takes almost twice as long to write code and tests then just code
• Its extremely easy to get out of the habit of writing tests.
• You'll refactor quicker and more often when writing tests
• Having testable code made me feel much better about sharing the code.

On the Happy Accidents site there's a new post talking about building a RESTful API (part one of the series) using the Orno dependency injection and MVC components.

have recently been writing a collection of PHP components exploring different design patterns for building applications. With the MVC layer close to completion I decided to write a couple of guides on how these components could be wired together to achieve several different application formats. First in this series will highlight the power of OrnoDi when used to resolve your objects, to do this we will be building a simple RESTful api with the minimal amount of configuration and bootstrap code.

He includes instructions to install the components (via Composer) and configure the DI container with the needed settings. He shows examples of the autoloading setup, how to handle the routing and how to create the sample model and controller to respond to the sample REST requests.

Matthew Weier O'Phinney has posted the third part of his series about making RESTful APIs with Zend Framework 2 (parts one and two). In this latest part of the series, he talks more about documenting the API and what commands can be executed.

In this post, I'll be covering documenting your API -- techniques you can use to indicate what HTTP operations are allowed, as well as convey the full documentation on what endpoints are available, what they accept, and what you can expect them to return. [...] hy Document? If you're asking this question, you've either never consumed software, or your software is perfect and self-documenting. I frankly don't believe either one.

He covers a few reasons why you should document your API and where he thinks it should live to be the most useful. He includes a few different ideas and two things he definitely thinks should exist for your API - the use of OPTIONS and end-user documentation. The first is a HTTP header (ZF2 code example included) that tells the API consumer what they can do with an endpoint. The second type is more useful for the human reader, giving them a better overall perspective on what the API can do - still served through the API but in a bit more understandable format.

Lorna Mitchell has officially announced the release of her O'Reilly-published book about creating and working with web services in PHP, PHP Web Services.

I'm delighted to announce that my new book "PHP Web Services" is now available as an early release! [...] The book isn't huge (or expensive, hint!), but it aims to give solid theory in a practical and approachable way. There's the topics you'd expect to see, covering HTTP and verbs and headers and status codes, and also around data formats. It also covers RPC services including SOAP, and also has a chapter (predictably the longest one!) about REST. I've tried to go beyond simply the "how to do" and into the "how to do in a kick-ass manner" realm, so there are chapters about how to design your API and choose what kind to build, how to handle errors, how to make your API really robust - and of course how to debug when things go wrong!

The book not only has the summaries and descriptions of some common web service challenges, but also includes code samples you can use in your own projects.

Matthew Weier O'Phinney has posted the second part of his series looking at creating RESTful APIs with the Zend Framework v2. In the previous post he covered some of the basics of data and structure. In this new article he looks at content types, status codes and two ways to represent them back to your users.

In my last post, I covered some background on REST and the Richardson Maturity Model, and some emerging standards around hypermedia APIs in JSON; in particular, I outlined aspects of Hypermedia Application Language (HAL), and how it can be used to define a generic structure for JSON resources. In this post, I cover an aspect of RESTful APIs that's often overlooked: reporting problems.

He starts with some of the things around error handling and APIs that bother him and why just returning a status code representing an error isn't enough. He suggests two possible solutions to this issue - two messaging formats, API-Problem and vnd.error. He gives brief summaries of each and includes example output to give them some context.