This section describes the features of the PHP language that support web services. Because this topic is represented in many other documents, this section focuses on the fundamentals and what makes PHP on IBM i so uniquely posed to deliver incredibly scalable web services.
Exploration includes both SOAP and RESTful approaches to web services in addition to the payload typically used in communicating between systems.
Payload, as the name implies, is the data that is transferred between systems. As a quick review, web services are a 21st century version of Electronic Data Interchange (EDI). Instead of x.12 as the payload, many web services communicate by using XML or JSON. Either method can be adequate for communicating most web services payload, but there are some fundamental differences. XML can deliver higher levels of accuracy, but at a performance cost because of the verbosity of the payload. The size of the package that is delivered by XML can easily be two to three times the size of JSON and can, therefore, add to the latency of a web service. JSON sacrifices some accuracy in favor of a lighter weight payload. Think of what you might be sending when you pick a method.
PHP impact on web services payload
PHP supports various payload types, including XML and JSON. But PHP can also support the native types of communication such as PHP arrays. The obvious limitation is that you must use PHP on both sides of the web service if you are going to pass a PHP array payload. Given the nature of web services that are trying to make the interconnected world of computer communication cross platform ubiquitous, you might be asking yourself why you might create a web service that generated only PHP arrays. However, many of the program calls of the future will evolve from hardened calls that are in RPG to loosely coupled requests, such as the ones we see in web services inside our own network. Therefore, if you know that there is PHP on both sides of the web service, you can pass a PHP array and enjoy the absolute fastest payload processing time that is available. One of the best implementations, however, allows for the payload to be configurable through the request. For example, a PHP web service client can ask the provisioning web service for a PHP array payload and thus improve the performance of both the server and the client. If, however, the request is denied, the performance impact is a single “if” test.
Other portions of this chapter have described various types of payload. The next section describes PHP and web services.
Simple comparison of XML and JSON
To illustrate the point of simplicity and gloss over detail and verbosity, here is the exact same data that is placed in a JSON format and then in an XML format.
As you can see from the preceding simple examples, there is a significant difference in the format of the files. XML is tag-oriented, and JSON relies on more flexible labels and a simple comma delimiter. In this simple example, this is not a major matter. However, look closely at the number of characters in the JSON example (Figure 5-35); there are about 181 with spaces. The XML package (Figure 5-36) has 292 characters, including spaces. The difference of 111 characters represents more than a 50% increase in the JSON payload size.
That might not seem like much, but consider what happens when the web service is refreshing the product master from one system to another and there are 5,000 products. Now you have potentially 111 characters times 5,000 products representing an extra 540 KB of data going across the pipe for no reason other than formatting.
As always, details about all of the functions that are described in this chapter can be found at http://www.php.net, the online documentation for PHP. There is an entire section on SOAP (http://php.net/manual/en/book.soap.php), but no section on REST. However, REST is an implementation of RPC and, therefore, the functions that are used to process these requests exist. We repurpose them for this chapter