PHP Web Services - Authentication Based on Client’s IP

This blog post PHP Web Services - Authentication Based on Client’s IP explains with code samples how a PHP web service can be written to authenticate clients based on their IPs.

REST Vs SOAP

Both REST ( Representational states transfer) and SOAP is widely adopted techniques for building distributed systems. REST is an architectural style for implementing systems on top of HTTP infrastructure.  A large number of Specifications has been developed on top of SOAP and there are large number of SOAP stacks both open source and proprietary out there implementing large part of this WS* stack.

Both these d techniques have their advantages and drawbacks. Here are few of the advantages and disadvantages of each paradigm.

REST

Advantages

1. Based on few simple principles which are already in wide adoption on the Web itself

2. Can be implemented very quickly.

3. Ideal for providing simple API's to the users. (Eq Whether Services, Flicker, Yahoo REST services )

4. Amount of learning required to get started is minimum in comparison to SOAP

5. Has a very large following amount the scripting community

Disadvantages

1. If the system is a very large one, then designing based on REST could become a very complex task.

2. Implementing Security on a REST system is one major issues. Although HTTPS, and HTTP Authentication can be used,  they only provide transport level security.

SOAP

Advantages

1. Well designed mature technology

2. Has been widely adopted in industry

3. Large number of SOAP stacks available to choose from.

4. Has support for Both Transport level and message level security which is a big advantage over REST.

5. Supports multiple protocol bindings ( Not just HTTP)

6. Ideal for implementing complex enterprise  systems since the SOAP Stacks cater for security, reliability, transactions ect.

Disadvantages

1. Complex in comparison to REST

2. Big learning curve required

3. Difficult to debug a complex system

One great thing about using WSF/PHP is that it can support Both of these techniques simultaneously. However, if you are building a complex system which require  security, I would always recommend the use of SOAP.

Data Services Best Practices

Is that data services are for converting database tables to web service operations?. Is that the right way to adapt SOA?. This post titled 'Data Services Best Practices' explains how you should develop data services without violating SOA principles

Sending Encrypted Binary Messages With PHP Web Services

Web services has made the communication between heterogeneous environments (say PHP with .NET or Java) a reality. It has defines standards for communicate not only with texts but also with binaries. And more importantly you can keep these communication confidential using encrypted messages according to your requirement. In the post "Sending Encrypted Binary Messages With PHP Web Services" , we will look at how we can implement such a system with PHP in one side.

PHP Data Services with PostgreSQL

If you are using postgreSQL as your backend database and you are wondering how to write a web service exposing data on there, this post will be a good guide for you, PHP Data Services with PostgreSQL.

Using command line to debug your Web Service

You can actually run your PHP Web Service on the command line. One may wonder what the use of doing that ?

The main use case is that, you can test your service, without having to write a client. It is specially useful, if your are following the code first approach.  You can find the code for actually doing this in one of the WSF/PHP samples. It is in fact the simplest sample of all. The echo_service.php.

Lets have a look at how this becomes possible.

 WSService->reply() function takes an optional string argument . 

1. You can pass the actual XML string expected from the client to the reply function. Then, the service can be executed on the command line to see the actual executed output from an operation.

However, this would work only in cases where you using SOAP Body dispatching or WS-Addressing.

In SOAP Body dispatching case, the XML qualified name of the child element of soap body is used to identify the operation which should be invoked.

In case of WS-Addressing, the addressing action header is used.

2. Lets look at a code sample on implementing this.  This is the echo_service.php sample that comes with WSF/PHP

<?php

$requestPayloadString = <<<XML
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
   <soapenv:Header/>
   <soapenv:Body>
     <ns1:echoString xmlns:ns1="http://wso2.org/wsfphp/samples">
         <text>Hello World!</text>
     </ns1:echoString>
    </soapenv:Body>
</soapenv:Envelope>
XML;

function echoFunction($inMessage) {

    $outMessage = new WSMessage($inMessage->str);

    return $outMessage;
}

$operations = array("echoString" => "echoFunction");

$service = new WSService(array("operations" => $operations));
$service->reply($requestPayloadString);

?>

I have highlighted the important code segments. Note how the Expected soap envelope string is passed to the reply() function as an argument.

3. Now you can execute this service on the command line and get the result.

php echo_service.php

Now you should see the expected output soap envelope after invoking the echoString operation.

4. You can also generate the WSDL for the service on the command line as well. Simply set the reply function argument string to "wsdl" or "wsdl2".

$service->reply("wsdl");

5. Now you can re execute the service and get the wsdl for the service on the command line.

php echo_service.php

This is a very useful feature for debugging your hand coded services  :).