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?
getEntityBody() – Return the raw entity body of the request, if present
It’s a very simple addition, but feel free to comment on my patch and offer any improvements or additions.
See also PUT method support in the PHP manual.
14 Comments »
Permalink
Tags: apache, atom, atompub, couchdb, delete, http, php, put, rest, zend, zend-framework, zend_rest_server
Wed, 21 Feb 2007 20:58 UTC
So, I popped into #apache on Freenode IRC today to ask a question. That’s when I noticed the news in their topic that ApacheCon US will take place this year in Atlanta, GA from November 12-16 at the Westin Peachtree. This is good news for me (since I won’t need to get a plane ticket) and Atlanta PHP!
I proceeded to ask Rich Bowen a few questions about the conference and what Atlanta PHP can do to help promote and take part in it. ApacheCon usually has a PHP track (ApacheCon EU does not have a PHP track this year), and Rich said he expects this conference to have the full complement of tracks. It’s my hope that Atlanta PHP can somehow be a part of this.
For now, there are no more details, and the CFP hasn’t been announced, but the dates (Nov 12-16) and location (Westin Peachtree) are “set in stone.”
No Comments
Permalink
Tags: apache, apachecon, atlanta, atlantaphp, conferences, php
Thu, 1 Dec 2005 3:26 UTC
A while back, when I was doing some research for a talk on server-side security for PHP, I looked into various “secure” methods for setting up a server for multiple users. Despite my search, I couldn’t find a simple and effective solution for managing a server with a large (and untrusted) user base (as is the case with many virtual hosting companies). Sure, there’s PHP’s safe_mode, but its “safety” is misleading at best. There’s also open_basedir, which helps a little, but it’s not quite enough. I also looked at jailing Apache (both the hard way and the easier way), but even then, all user directories have to be in the root jail, and any user can still read the readable and write to the writable files of another user in the jail.
For my research, I also looked at and tested mod_security, the goal of which is to secure applications from the Apache Web server, and the Hardened PHP Project’s Hardening Patch, which secures PHP applications from the language engine. Both of these are excellent tools and should be assessed by anyone seeking to “harden” their server configuration.
Still, I wanted to find something that would split off Apache so that each user’s site was running as that user instead of the general Apache user that could read and execute all user files. This global user serving and processing all pages is where the root of the problem lies. Yet, if Apache could serve each site as the owner of the site, then the owner’s file permissions could essentially be set to 700 (instead of being world/group readable for the Apache user) and Apache would still serve the pages since it’s running as the privileged user. Even better, run Apache with this configuration, and place it and the system users in a jail; no one would then be able to access any system files or the files of other users.
No matter how many people I asked, I couldn’t find an easy answer for how to do this.
Around that time, someone suggested I look into Metux MPM for Apache, but, from what I understand, Metux uses threading, and running PHP in a threaded environment is not recommended, so the solution needed to be non-threaded.
Finally, via a comment on Christopher Kunz’s blog, I’ve found something that, at least, sounds like what I’m looking for. It’s the Peruser MPM by Telena Internet Services, and it seems that it was created with PHP in mind.
Here’s what the site says about Peruser:
The fundamental concept […] is to run each apache child process as its own user and group, each handling its own set of virtual hosts. Peruser […] can also chroot() apache processes. The result is a sane and secure web server environment for your users, without kludges like PHP’s safe_mode. […] I created Peruser, which provides multiple processes for each unique user/group/chroot.
The site warns against using it in production, and it warns that it breaks mod_ssl and renders Apache not as scalable, but it sounds like a step in the right direction. I’m putting it on my radar to test soon.
6 Comments »
Permalink
Tags: apache, hardened-php, mod_security, peruser-mpm, php, security
Thu, 26 Feb 2004 14:09 UTC
Rich Bowen mentioned this little “feud” in a short post on his Web site. According to the GNU web site, the Apache Software License version 2.0 (ASL 2.0) is listed as being incompatible with the GPL. Apache claims they have no clue where this comes from, and they stand by their belief that the ASL 2.0 is, in fact, compatible with the GPL. Apparently, it is believed that Slashdot may be fueling this “inaccurate” perception.
If the ASL 2.0 is compatible with the GPL, then there would be no need to include the aforementioned exception when including ASL 2.0 code in your GPL’ed applications.
No Comments
Permalink
Tags: apache, gnu, gpl, licensing
