PowerBuilder’s prowess to be able to enable Win32 and Win64 native applications to directly interact with the Internet universe started when Sybase added the iNet object class to the PowerBuilder System Class area.  The iNet object object’s methods allowed native PB apps to link out to a specific URL via the LinkToURL command, send data to a specific URL via the PostURL command and/or read data from a URL via the GetURL command. While this is still in PowerBuilder 2017 R2 for backwards compatibility, its functionality limitations and security vulnerabilities (only supports up to TLS 1.1) definitely makes it worthwhile to explore the new HTTPClient object, which we will discuss in this blog.

Figure 1- iNet object as seen in the PB IDE's Object Browser

In modern-day Internet interactions, applications often require more advanced functionality within their URL processing and support for at least the TLS 1.2 protocol is a must. Thus, starting in PB 2017 R2, Appeon added the HTTPClient object to the PowerBuilder’s System Class area. The HTTPClient object is designed to take over from the iNet object and to provide key advanced features that were requested of the iNet object even way back in the Sybase days of PowerBuilder but were never implemented. Some of these key advanced Internet features requests were to: set Request Header(s), read a Response object’s Header or Body, get the Response Code from a Request, process binary data, handle JSON data, and of course support TLS 1.2.

You may be wondering why Appeon didn’t just enhance the iNet object?  One of the key reasons for introducing a new HTTPClient object class rather than revamping the existing iNet object was to avoid iNet object class behavioral changes that could break existing apps when migrating to newer PowerBuilder releases. The other key reason was an entirely new implementation was necessary so that the RESTClient object (covered in another blog) could make use of the HTTPClient.  This was important design consideration by Appeon such that PowerBuilder would have a modularized and extensible architecture.