Currently browsing zend-framework

POST vs. PUT

Mon, 9 Nov 2009 16:07 UTC

This morning, Matthew writes about building RESTful services with the Zend Framework. I have a lot of thoughts on his post, and I might blog more about it later, but right now, I want to focus on David’s comment:

I think the next thing you should cover is how to retrieve put parameters and maybe even attempt to start a discussion on the different school of thoughts about POST vs PUT (Especially in the PHP world).

I know I’m even guilty of mentioning different schools of thought on POST vs. PUT in my talks, but the truth is that REST doesn’t specify what to use for what actions. These are defined by HTTP and not by REST.

Roy Fielding has this to say about the use of HTTP verbs in RESTful applications:

Some people think that REST suggests not to use POST for updates. Search my dissertation and you won’t find any mention of CRUD or POST. The only mention of PUT is in regard to HTTP’s lack of write-back caching. The main reason for my lack of specificity is because the methods defined by HTTP are part of the Web’s architecture definition, not the REST architectural style. Specific method definitions (aside from the retrieval:resource duality of GET) simply don’t matter to the REST architectural style, so it is difficult to have a style discussion about them. The only thing REST requires of methods is that they be uniformly defined for all resources (i.e., so that intermediaries don’t have to know the resource type in order to understand the meaning of the request). As long as the method is being used according to its own definition, REST doesn’t have much to say about it.

The POST vs. PUT debate, however, does rage on in different communities, and some protocols have defined their usage. For example, the Atom Publishing Protocol (RFC 5023) explicitly states in section 4.3 that “POST is used to create” and “PUT is used to edit.”

The important thing to note is that REST doesn’t care how the HTTP verbs are used, as long as they are used properly according to how they are defined in the protocol you are using.

For those interested, HTTP (RFC 2616) defines POST by saying:

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. […] The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.

PUT is defined as:

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

With this line of thinking, you might come to the conclusion that POST is used for creation of a subordinate resource, while PUT could be used for both creation or modification of a resource. The important distinction is that POST identifies the resource for which the entity should be considered a subordinate; PUT does not.

Comments 10 Comments »  Permalink Permalink  Tags Tags: , , ,

Supporting PUT & DELETE in the Zend Framework

Wed, 27 Feb 2008 18:51 UTC

Creating a RESTful Web service is not simply about serving read-only content through HTTP GET requests. It’s about using the full range of HTTP’s constrained interface to allow clients to consume or create resources within your service. Take a look at CouchDB, for example. Its initial releases look very promising, and the server accepts GET, POST, PUT, and DELETE requests to manipulate resources in the system. I can’t wait until the project implements authentication and authorization features; then, it will look much more attractive for real-world use.

But I digress…

I’ve never been too happy with the Zend Framework’s RPC-based approach to creating RESTful Web services with Zend_Rest_Server, even though I have seen some good discussion about using routes and Zend_Rest_Server to create a resource-oriented architecture. Rather than get too in-depth about this issue, I’ll just point to this thread and save my full thoughts on Zend_Rest_Server for another day.

Suffice it to say, Zend_Rest_Server is not focused on resources but, instead, what you can do with those resources (procedures, methods, verbs) and also assumes you’re only ever going to provide an XML-based, read-only REST service. With REST, this is not the case, and, with the publication of the Atom Publishing Protocol (a protocol that follows the REST architectural style) as RFC 5023, now is the time more than ever to grasp the read-write capabilities of the RESTful Web.

But I digress (again)...

I’ve recently been wrapped up in an effort to design and implement a RESTful API using the Atom Protocol for a project at work. We are using the Zend Framework as the underlying framework for the project, so, in order to follow the Atom Protocol, I needed to support the HTTP methods PUT and DELETE. Apache can handle GET and POST easily because the request itself tells Apache the resource to use when processing the request. With PUT or DELETE, the resource identified by the request may not even exist, so Apache needs you to specify a script to process the request. To do this, I added the following lines to my virtual host configuration:

# PUT and DELETE support
Script PUT /index.php
Script DELETE /index.php

Now, all PUT and DELETE requests are handled by the Zend Framework bootstrap script and the dispatcher handles them in the same way it handles GET and POST requests.

To further support other HTTP methods and the REST architectural style, I’ve proposed the addition of the following methods on the Zend_Controller_Request_Http class:

  • isGet() – Was the request made by GET?
  • isPut() – Was the request made by PUT?
  • isDelete() – Was the request made by DELETE?
  • isHead() – Was the request made by HEAD?
  • isOptions() – Was the request made by OPTIONS?

Zend Framework View Notes

Thu, 5 Apr 2007 3:09 UTC

I’ve been working a lot lately with the Zend Framework for a project at work, and in a recent upgrade from 0.8.0 Preview to 0.9.1 Beta, I made a few discoveries that I’d like to share, especially since the manual for the Zend Framework is sorely out of date, and many of the examples are either deprecated or no longer work.

Most notably, I’ve started using the “new way” of using views, which is still undocumented in the manual. Rather than create a new Zend_View object, tell it where my views are, and echo a call to its render() method, I’m letting the controller’s render() method do it all for me. To do this, you need to follow a specific directory structure. For example, if your application is set up like this:

application/
    controllers/
    models/
    views/
library/
    Zend/
    Zend.php
webroot/
    index.php

Then, to make use of the controller’s default render() behavior, add a scripts/ directory under the application/views/ directory. Then, inside the scripts/ directory, create a directory for every controller. The directory must have an all-lowercase version of the controller name without the word “Controller.” So, if you have a CustomerController class, then the directory would simply be customer/.

Inside this directory, create a view file for every action you will render following the same naming conventions. Thus, if you have an indexAction() and an addressAction() you would have the files index.phtml and address.phtml in application/views/scripts/customer/. The .phtml extension is the default for views in the Zend Framework; see Rob Allen’s discussion on the use of the .phtml extension.

Finally, to use the views, you’ll need to initialize them in your controller. Do this by creating an init() method and calling $this->initView() from within it. This sets up the default view for your controller. From within any action, you may now set properties on your view as normal with $this->view->propertyName and you can render the view with $this->render() (there is no longer a need to echo).

So, to recap, with a directory structure like this…

application/
    controllers/
        CustomerController.php
    models/
    views/
        scripts/
            customer/
                index.phtml
                address.phtml
library/
    Zend/
    Zend.php
webroot/
    index.php

... and a controller like this …

<?php
 
class CustomerController extends Zend_Controller_Action
{
    public function init()
    {
        $this->initView();
    }
 
    public function indexAction()
    {
        $this->render();
    }
 
    public function addressAction()
    {
        $this->render();
    }
}
 
?>

... you can much more easily work with views in the Zend Framework.

Note that Zend_Controller_Action::initView() determines the location of the views directory on its own, so you don’t have to tell the application where your views are stored. It determines the location based on the controller directory specified for the current module in use. In this case, we’re using the “default” module, and I’ve specified the controllers directory in my front controller as /path/to/application/controllers/. The Zend Framework also supports the use of different modules using different controller directories, but I’ll talk more about that later as I share more of my Zend Framework discoveries.

Comments 21 Comments »  Permalink Permalink  Tags Tags: ,

Zend Framework on Ning

Thu, 24 Aug 2006 7:29 UTC

I couldn’t sleep tonight, so, instead of doing one of the many other things on my plate that I need to actually work on, I decided to set up the Zend Framework on Ning so that others could clone it and use it for their Ning applications. If you’re unfamliar with Ning, here’s what the Ning developer documentation says about itself:

Ning enables regular everyday people with no design or development skills to get their own copy of real, working social web applications and adapt them for any need or niche. But that’s not all. Everything running on Ning is 100% programmable. This means web designers, developers, or adventurous amateurs can dive into any App or feature running on Ning and change it.

Now, on to the good stuff. I’ve set up a fully functional application using the Zend Framework on Ning. Thus, the application structure, URL mapping rules, and bootstrap file are all in place and working. All you need to do is clone the app and get to work on building your Zend Framework application on Ning. I had to make a few slight modifications to the Zend Framework (mostly with respect to $_SERVER[‘REQUEST_URI’]), but those are noted in the notes I provide on the Zend Framework Ning site.

So, go to the Zend Framework Ning site now and get started playing with the Zend Framework and Ning!

NOTE: Ning is running PHP 5.0.4, so there may be some parts of the Zend Framework that do not work, since the ZF requires PHP 5.1.4. If you run across these, please note them in a comment here, and I’ll note it on the Ning page for the Zend Framework.

Comments 1 Comment »  Permalink Permalink  Tags Tags: , , ,

Vaporware No More: Zend Framework Available

Sat, 4 Mar 2006 19:40 UTC

A preview release of the Zend Framework is now available, and, so far, I must say that all looks well.

The one thing that I’m a bit curious about is the apparent removal of the Active Record implementation, Zend_Db_DataObject. The documentation for this object exists in the Programmer’s Reference Guide, but it’s nowhere to be found in the API. I wonder whether the implementation exists in a different form in Zend_Db, or was it scrapped altogether?

The Active Record implementation aside, one of the other features I was looking forward to was the Zend_InputFilter framework. I know that Chris will undoubtedly write much more about this, but I wanted to point out one very cool feature: the strict mode.

The strict mode works like this: you pass an array of tainted data (let’s say the $_POST array) to Zend_InputFilter to create a new object to access the data in a safe manner, and, then, by default, $_POST is set to NULL for the remainder of the script—you simply cannot access the raw, tainted data from $_POST. Here’s an example:

<?php
 
$filterPost = new Zend_InputFilter($_POST);
$username   = $filterPost->isAlpha('username');
 
var_dump($username); // will either contain the value of 
                     // $_POST['username'] (if it contains only 
                     // alphabetic characters) or FALSE
var_dump($_POST);    // will print NULL
 
?>

This strict mode could be very useful in an environment with a team of application developers. Just set auto_prepend_file in php.ini to load up a script that grabs all autoglobal variables ($_POST, $_GET, $_COOKIE, etc.) and stores them to Zend_InputFilter objects, and you never have to worry about your team accessing raw data—they must always use the Zend_InputFilter object to get to the data. (There is a getRaw() method of this object, but I’ll let Chris discuss it in more detail.)

Finally, lots of folks are already talking about this. Here are some links:

Comments No Comments  Permalink Permalink  Tags Tags: , , , , ,

PRO::PHP Interview With Andi

Fri, 27 Jan 2006 19:14 UTC

Today, PHP Architect and Pro PHP Podcast held their first live podcast (Interview with Andi Gutmans) since PHP Architect announced their “acquisition” of the podcast. However, due to some technical difficulties, the live feed was canceled after about fifteen minutes into the interview, and the audience was unable to participate in the Q & A session at the end.

Nevertheless, I do have a few notes from the interview to share.

PHP Collaboration Project
The Zend PHP Collaboration Project, often referred to as the “Zend Framework,” was on the minds of many of the attendees as the interview began, and Marcus Whitney dove right into it, asking Andi why Zend decided to undertake this project. Andi said that Zend feels there are three things needed to take PHP to the next level; the PHP Collaboration Project is made up of these three things:

  • a solid framework/development environment
  • enriched development tools (Eclipse)
  • best practices

    Zend is using the PHP Collaboration Project as a vehicle to promote and accomplish these goals to advance PHP.

    PHP Competing With .NET
    Marcus asked Andi why he has been quoted in the past as saying that Java is not PHP’s main competition, but, rather, .NET provides the most competition. Andi ellaborated on this, saying that the Web is moving toward a more agile development model, which is why he feels that Java is not particularly suited for the Web. Instead, .NET and PHP are both particularly suited to solve the Web problem, and so it is only natural for .NET to be PHP’s main competition.

    PHP Strengths
    Andi continued his discussion of PHP vs. .NET by highlighting the major strength of PHP and the main weakness of Microsoft (and, thus, .NET). He said that the greatest strength PHP has is its large community base, while Microsoft has never been able to solidify itself in the server market over Apache—the software giant’s greatest weakness in the competition against PHP.

    At this point in the interview, the technical difficulties took over and the audience was unable to participate in the remainder of the interview, so this blog post serves merely as a teaser. I believe they’ll post the rest of the interview by Monday, though, so look for it, then.

    Comments 2 Comments »  Permalink Permalink  Tags Tags: , , ,