In PHPMaster.com's latest tutorial Lukas White introduces you to using the Yahoo "Placemaker" web service to geographically locate a place from a free-form text string. The results include "place details" like the type of the location, latitude, longitude and how confident they are in their match.

The challenge then is to do two things: work out what place you could be talking about, disambiguate if necessary, and then identify exactly where on Earth that is. That's what I'll show you how to do in this article; by using a freely available web service, we'll write a simple program to ask users where they are (and ask them to clarify if necessary) before identifying their responses in concrete terms.

He shows how to make a request to the Placemaker web service, passing it a string coming from the user, to be located. The POST request contains a few pieces of data including an application ID , your desired output type and the language you're using for the input. His example code uses curl to make the request and handles it (the XML response at least) with a call to simplexml_load_string.

In this new post to her blog Lorna Mitchell starts off a new series (based on popular demand) looking at building an RESTful server in PHP. Back to basics - no framework, just PHP.

In the first part of this (probably) 3-part series, we'll begin with the basics. It might seem boring, but the most important thing to get right with REST is parsing all the various elements of the HTTP request and responding accordingly. I've put in code samples from from a small-scale toy project I created to make me think about the steps involved.

Her "basics" include:

• the routing to send everything to the main index file (a "front controller" of sorts) with the .htaccess settings included
• Handling the incoming request with a "Request" class
• Parsing the incoming parameters from the "php://input" stream

New on PHPMaster.com there's a tutorial from Lukas White about targeting users using geolocation based on the Geonames web service and a latitude/longitude. His example makes a call to find the closest "place" to the given coordinates.

Location-aware applications rely on being able to locate where you are, and this is what geolocation is all about. After all, once the application knows your location, it can go on to find the nearest store, guide you through the appropriate route to a destination, or target relevant advertisements to you. Geolocation, then, is simply the mechanism for identifying your geographical location.

He mentions two challenges associated with geolocation - finding where someone is and describing the location. With Geonames, he shows how to call the service's "findNearbyPlaceName" method to find the closest "place" to a given latitude/longitude combination. Included is a bit of sample PHP to connect to the service and Javascript to request the user's current location.

Continuing on with his webcast series looking at using the Slim microframework to create a RESTful web service with JSON Output, John Lebensold takes the code from the previous tutorials (part one, two, three) and adds handling for DELETE to remove values from the data.

This tutorial will show you how to add jQuery RESTful calls for using the DELETE verb when deleting items via a JSON REST interface.

You'll definitely need to check out either the previous tutorials in the series to follow along with the code or grab the current source to see how everything's structured.

In this new post to Reddit.com, the question is asked "Should I be doing just about everything using REST?" - wondering if their new applications should all sit on top of a web service for their functionality.

I'm pretty new to server-side programming, and actually started out with Python/mod-wsgi. From the ground up, mod-wsgi made a lot of sense. The server gets a request, you route the request. It feels like that's where I should start, so that's pretty much what I'm trying to create with PHP (a REST router - for learning purposes, I know frameworks exist). I'm trying to think of a situation where I wouldn't use a REST interface, but I can't seem to think of one (even for simple cases). Would it be safe to say that using REST is a pretty safe bet, most of the time?

There's some good discussion and answers to his question touching on things like Service Oriented Architectures, some implications of having a web service power an entire application (or applications) and a few comments with some personal experience.

A comment about SOA sums it up well:

You learn to write for your platform in the way developers/partners will have to, so you produce a good quality usable API which encourages development and consumption of your platform.

On the php|architect site today Chris Tankersley has a new tutorial about geocoding, Finding Exactly Where You Are - a guide to integrating the Yahoo! Placefinder service into your application.

Yahoo! PlaceFinder is a REST web service that will turn an address into the latitudinal and longitudinal coordinates in XML, JSON, or serialized PHP objects. It has a few other functions too, like finding the nearest airport, time zone, and even telephone area code. [...] PlaceFinder is a very simple REST service, so cURL is a quick and easy way to access it. There are no authentication tokens to deal with or logon procedures. Just send a GET request, and read the response.

He links you to the service to get an API key and includes a simple class (PlaceFinderAPI) that builds the GET query for you and makes the request via curl. Also included is an example showing how to find a given location (coincidentally, his location choice is the hotel where the php|tek conferences are held).

New on PHPBuilder.com today is a tutorial introducing you to web services with the Zend Framework, a guide to creating a simple RESTful service with this popular PHP framework.

Rather than attempt to build and maintain multiple versions of the Web application in order to accommodate the diverse array of challenges and advantages presented by each device type, developers are increasingly embracing a unified approach which allows them to manage a single server-side code base which communicates with multiple client-specific interfaces by way of a RESTful Web service. The Zend Framework's Zend_Rest component offers PHP developers with an incredibly straightforward approach to building RESTful Web services.

He shows how to set up some internal RESTful routing (with the help of Zend_Rest_Route) and create a simple controller that responds to several of the major HTTP request types - POST, GET, PUT, etc. In his simple example, he shows how to update a basic TODO list with a POST and the JSON response that would follow.

On ZendCasts.com today, the next part of their series looking at using the Slim microframework has been posted. This is part one of a tutorial building a JSON endpoint for a web service.

You'll need some of the base that he created in this previous screencast to follow along (the basic structure, really). His takes his basic "hello world" application and builds on it to add a "model" to pull name data from and has the "/names" action respond with a JSON-formatted message (and an "application/json" content-type). His "model" pulls the data out with findAll() and find() methods.

You can grab the source to follow along.

In a new post to his blog Philip Norton shares a method for creating a thumbnail of a Word document with the help of PHP and LiveDocx (in this case, the component inside the Zend Framework).

Creating Word document icons is very simple thanks to a service called LiveDocx. LiveDocx was created as a web service to allow the easy creation of most document formats from a simple template. However, it is possible to send a normal Word document as the template file and get an image of the file in return.

You'll need a LiveDocx account to be able to use the service - there's a free option of their service that uses a shared server. Included in the post is a sample script that defines a LiveDocx connection, pulls in a local Word document for parsing and calls a "getBitmaps" method on the service to return the raw image data. This is pushed into an image (using GD) as a PNG.

Håvard Eide has a new post sharing a tool he's created (based on some ideas presented in this netflix blog post) for testing a web service. Specifically, his tool helps you test a web service developed with the Slim framework.

I just pushed a example on how to create a Slim framework to github. The idea is that whenever you create a webservice with the Slim framework (which is really simple) you rarely test for failure, the ChaosMonkey class will help you to do just that. When initialized with the AbsoluteChaos plugin it will randomly kill the webservice with exceptions, garbage to the output, or just run the service for you without failure at all.

His plugin does a lot of things right now, but it's easy to extend with your own failure types - like his suggested "networkSleep" or something that could kill the connection to MySQL. He includes a code snippet in the post of how to hook Slim and ChaosMonkey together for some testing fun.