News Feed

News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way Blog:
Using the Accept Header to version your API
October 20, 2014 @ 12:56:46

On the blog today there's a new tutorial talking about the use of the Accept header in REST HTTP requests and, more specifically, working with it in a Symfony-based application.

I investigated different ways to version a REST API. Most of the sources I found, pretty much all said the same thing. To version any resource on the internet, you should not change the URL. The web isn't versioned, and changing the URL would tell a client there is more than 1 resource. [...] Another thing, and probably even more important, you should always try to make sure your changes are backwards compatible. That would mean there is a lot of thinking involved before the actual API is built, but it can also save you from a big, very big headache. [...] Of course there are always occasions where BC breaks are essential in order to move forward. In this case versioning becomes important. The method that I found, which appears to be the most logical, is by requesting a specific API version using the Accept header.

He shows how to create a "match request" method in his custom Router that makes use of the AcceptHeader handling to grab the header data and parse it down into the type and API version requested. He also includes an example of doing something similar in the Symfony configuration file but hard-coding the condition for the API version by endpoint.

0 comments voice your opinion now!
accept header rest api versioning symfony tutorial


Mathias Noback:
Semantic versioning for bundles
September 30, 2014 @ 11:26:40

In a recent post to his site Mathias Noback looks at the use of semantic versioning, introducing some of its basic concepts and how it can relate to the work done in Symfony bundles.

Semantic versioning is an agreement between the user of a package and its maintainer. The maintainer should be able to fix bugs, add new features or completely change the API of the software they provide. At the same time, the user of the package should not be forced to make changes to their own project whenever a package maintainer decides to release a new version.

He breaks down what the version numbering represents (major, minor and patch versions) and how they work with Symfony's "semver" to handle issues that come with backwards compatibility concerns. He then looks at a few things to consider when versioning your bundles and how it relates to the underlying libraries it might use:

  • Bundles expose an API themselves
  • The API of a bundle leads a life on its own
  • A library may contain bugs that are totally unrelated to the bundle
  • A library may contain features that are not implemented by the bundle

Ultimately, he suggests that bundle versioning should have nothing to do with the underlying libraries/packages. It's his opinion that they should only be reversioned when there is a change in the actual bundle.

0 comments voice your opinion now!
semantic versioning symfony bundle package library opinion


SitePoint PHP Blog:
Database Versioning with Ladder Migrations
April 22, 2014 @ 10:48:41

The SitePoint PHP blog has posted another tutorial looking at database versioning (see this postfocusing on Ladder migrations. Ladder is a simple PHP-based way to write migrations with rollbacks in a clear, easy to read format.

Version control systems are invaluable for tracking changes in your code, particularly when you're working in a team. However, most applications don't consist solely of application code. Managing changes to the database has always been a little more challenging, particularly when you're adding new features which require changes to the schema. [...] One solution is to move responsibility for creating and modifying the database schema into code, using migrations. That way, changes can be managed along with the rest of your application, and features we take for granted in version control - such as being able to compare versions and keep an audit trail - can be used for database changes.

He introduces the Ladder tool briefly, shows how to get it installed/configured and gets into writing a first simple migration. It creates a "users" table with two columns and comes with both "up" and "down" methods to make rollbacks easier. Ladder also provides functionality for database seeding, pre-populating the database tables with sample data either from hard-coded values or from a CVS file.

0 comments voice your opinion now!
database migration ladder versioning tutorial project

PHP objects in MongoDB with Doctrine
March 21, 2012 @ 10:03:59

On today Giorgio Sironi has a new post showing how you can use Doctrine with MongoDB to work with Document objects from the database.

In the PHP world, probably the Doctrine ODM for MongoDB is the most successful. This followes to the opularity of Mongo, which is a transitional product between SQL and NoSQL, still based on some relational concepts like queries. [...] The case for an ODM over a plain Mongo connection object is easy to make: you will still be able to use objects with proper encapsulation (like private fields and associations) and behavior (many methods) instead of extracting just a JSON package from your database.

He briefly mentions that the PECL extension for Mongo needs to be installed prior to trying out any of the examples. His first example shows how to create a DocumentManager (similar to the normal EntityManager for those familiar with Doctrine). He also shows an integration with the ORM and shares some of the findings he's made when it comes to versioning the resources (hint: annotations are your friend).

0 comments voice your opinion now!
mongodb doctrine object orm tutorial versioning

Tilllate Blog:
Caching of Dynamic Data Sets
December 05, 2007 @ 10:29:00

On the Tilllate Blog, there's a new post discussing the use of caching in applications, specifically for dynamic data.

Consider you have a set of data that is changing dynamically for each page request and you need to cache that data the fastest way possible. You can't cache dynamic and unpredictable data as a whole, can you? Hence, we would put each data entry into cache separately to be able to fetch it separately and dynamically. But this means bombing your cache infrastructure with with requests.

They break it up into a few different topics - caching text elements on the page, two-tiered caching (grouping cached items), incremental caching and cache versioning. They don't share an example of their code unfortunately, but they do mention something about a possible contribution to the Zend_Cache component of the Zend Framework.

0 comments voice your opinion now!
caching dynamic data text element incremental versioning cache caching dynamic data text element incremental versioning cache

Community Events

Don't see your event here?
Let us know!

security extension library language opinion api introduction release podcast framework voicesoftheelephpant interview php7 video laravel5 laravel version series community example

All content copyright, 2015 :: - Powered by the Solar PHP Framework