For those dealing with APIs on a daily basis (or even the casual API-er) you'll find this post from Phil Sturgeon interesting. In it he takes on the opinion that's shared in this article from Pakal De Bonchamp that "REST is the new SOAP".

Enough people have asked me about the article REST is the new SOAP that I felt it justifies a write up. [...] The entire article is full of common misunderstandings about REST and HTTP. Despite dedicating my career to trying to educate people through these confusions, they continue to be rife. Clearly I am not being loud enough, writing effectively enough, or doing a good enough job. That is the frustration you might hear in my writing, but nothing is aimed at the author.

In his post Phil goes through the original article, pulling out quotes and responding to them one at a time. He shares opinions on HTTP verb operations, REST architecture, HTTP response code usage and the use of caching and statelessness in the API functionality.

The Zend Framework blog continues on its series of posts showing how to create various types of web services using various components from the framework itself. In this latest post they show you how to implement a SOAP server with zend-soap, a component specifically designed to "create, serve, and access SOAP applications, and parse and generate WSDL".

zend-soap provides a full-featured SOAP implementation. SOAP is an XML-based web protocol designed to allow describing messages, and, optionally, operations to perform. It's similar to XML-RPC, but with a few key differences: arbitrary data structures may be described [and] multiple operations may be described in a message as well.

The post goes on to talk about why they're show how to use these other service types when they primarily use REST in Apigility. It also covers some of the benefits using the module has over PHP's own SOAP handling. From there it's all about the code: first just creating the server and then populating it with the classes and functions it allows. The remainder of the post is split between two other methods for setting up the server: using it in a MVC application and as middleware in something like Zend Expressive.

Benjamin Eberlei has a new post today looking at the future of SOAP in PHP for the upcoming year. In his opinion, despite negative comments and harassment the technology gets, it still has the advantage over REST.

These last years REST has gotten all the buzz, everybody seems to be using it and there are lots of talks about REST on conferences. SOAP used to be big for building APIs, but everybody seems to hate it for various reasons. I have used SOAP in several projects over the last 10 years and this blog post is a random collection of information about the state of SOAP in PHP 2014, as a reminder to myself and to others as well. Why care about SOAP in 2014? For server to server (RPC) communication it still has massive time to market and stability benefits over REST.

He points out some things REST lacks like a standard to describe endpoints and a way to automatically generate clients in any language. He then gets into some of the basics of SOAP and PHP's included functionality. He shows some of the configuration options you can use for things like debug output, exceptions and custom exception handlers. He recommends the Zend Frameworks SOAP Autodiscovery for generating WSDLs and the XSD-TO-PHP library to create objects from a well-defined WSDL. He covers the different modes you can use to "talk SOAP" and using the ZendSoapClientLocal to make a request without the need of a web server.

Lorna Mitchell has officially announced the release of her O'Reilly-published book about creating and working with web services in PHP, PHP Web Services.

I'm delighted to announce that my new book "PHP Web Services" is now available as an early release! [...] The book isn't huge (or expensive, hint!), but it aims to give solid theory in a practical and approachable way. There's the topics you'd expect to see, covering HTTP and verbs and headers and status codes, and also around data formats. It also covers RPC services including SOAP, and also has a chapter (predictably the longest one!) about REST. I've tried to go beyond simply the "how to do" and into the "how to do in a kick-ass manner" realm, so there are chapters about how to design your API and choose what kind to build, how to handle errors, how to make your API really robust - and of course how to debug when things go wrong!

The book not only has the summaries and descriptions of some common web service challenges, but also includes code samples you can use in your own projects.

On the Codeception blog (an up and coming PHP-based testing tool) there's a new post showing how to use the tool to test your web services for either a SOAP or REST-based service.

Codeception testing framework got significant improvements during last week. The first and the major one is that you don't even need PEAR and Composer to execute tests. Only one file codecept.phar required. This might save your time and mind of your testers.

They've recently added modules for SOAP and REST support, making it easier to define your tests in a more fluid fashion. Included in the post are two examples, one REST and one SOAP. You can find more information about these new testing features over in the tool's documentation.

For those fans of virtualization (and running VMs for development) you're not stranger to VirtualBox. Over on the Google Code site, there's a project that wants to make it easier to work with your VirtualBox instances via a PHP-driven interface.

An open source, AJAX implementation of the VirtualBox user interface written in PHP. As a modern web interface, it allows you to access and control remote VirtualBox instances. Much of its verbage and some of its code is based on the (inactive) vboxweb project. phpVirtualBox was designed to allow users to administer VirtualBox in a headless environment - mirroring the VirtualBox GUI through its web interface.

The tool isn't designed to be a management tool for a "hosting" type of environment, but rather to help you admin all of your VMs at once (no "ownership"). It uses the SOAP service (vboxwebsrv) that comes with VirtualBox servers to create a clean interface.

On the php|architect site today there's a new article from Luke Stokes asking a question about the future of the web (and web serivces) - is the future in REST or SOAP?

I was recently asked why we chose REST over SOAP for our re-write of the FoxyCart.com API, and the short answer that immediately came to mind was, "Because I don't hate myself". To expand on that answer, let me give you a little bit of the back story.

He talks about their goals for the product and its API, how they wanted to create something useful, built by developers for developers. They leaned towards REST mostly because of the problems and overhead introduced with SOAP (and the complex nature of its requests). He also gives a few reasons why he's "excited about REST": working with known data types, standard interface methods and the fact that it's still such a hot topic of discussion.

These questions [about HATEOS, hypermedia, vendor-specific content types] might seem overwhelming, but for us they are exciting! We believe the future of consistent, powerful API development is being defined right now, and we get to be a part of it.

On PHPMaster.com today they've posted the second part of their series looking at creating a SOAP web service with NuSOAP. (Part one is here)

In this article we’ll talk about what WSDL files are and how to use them. I’ll show you how to quickly build your WSDL files with NuSOAP and incorporate a WSDL file into the SOAP server and client examples from the first part.

He introduces WSDL files, the specially formatted XML definitions that tell SOAP clients what's available on the service and includes some markup as examples. Creating one from scratch ca be a hassle, so it's handy that NuSOAP generates one for you from your server class. He includes sample code to create this generated file and how to create a SOAP client pointed to the PHP script to get the result.

On PHPMaster.com today there's a new tutorial posted, the first part in a series, showing how to create SOAP web services with the help of the NuSOAP library.

In this first of a two part series on web services I’ll talk about the SOAP specification and what is involved in creating SOAP messages. I’ll also demonstrate how to create a SOAP server and client using the excellent NuSOAP library to illustrate the flow of SOAP. In the second part I’ll talk about the importance of WSDL files, how you can easily generate them with NuSOAP as well, and how a client may use a WSDL file to better understand your web service.

He introduces you to the concepts behind SOAP, the normal structure of a SOAP-formatted XML message and what an example might look like for fetching a stock price from a remote service. He then shows how to use NuSOAP to create both a simple server and client to pull information about books - sample code and a screenshot of the output is included.

New from the King Foo blog there's a tutorial showing how to use complex types in a SOAP request with Zend_Soap, a component of the Zend Framework.

To be able to use complex types with Soap requests, they need to be fully defined in the WSDL file. Zend_Soap can automate this process, if you know how to define those complex types. Let us start without it Zend_Soap's magic and compare it with a fully discovered complex request type afterwards.

In their example, they have a collection of books (objects) that they want to send over to the web service. The code for both the server and client side are included with the WSDL automagically created by the Zend_Soap_Server component. By setting docblock comments on the properties of the Book objects, the SOAP components automatically know what types they are. Their example defines these, and sets up the web service on the other side with a classmap to define where the "tags" information for each book lies.