Using the WooCommerce API in mobile development

WordPress is (in my opinion) the best content management system to be used as a backend for developing mobile apps. Some app projects utilize Adobe’s PhoneGap, which is a technology that combines HTML, CSS, and JavaScript in a web browser view to connect a phone to the WordPress install. While this does the job, PhoneGap does not deliver a true native app. At Zeek, we emphasize native and hybrid code that interfaces with WordPress through various APIs. This enables us to deliver a high quality product that functions better than its PhoneGap counterparts might. However, we recently ran into problems creating an iOS app with eCommerce.

We selected WooCommerce as our eCommerce platform, as it has become the gold standard for WordPress storefronts. WooCommerce has a JSON API, but as we have discovered, it appears that it was designed primarily for administrative purposes. It has very little usable functionality to offer a customer-facing mobile app. I was brought in to help implement parts of the API that weren’t in the WordPress or WooCommerce JSON APIs.

WARNING: This post is about to get real. And by “real,” I mean “technical.”

Here is a list of the shortcoming in the WooCommerce RESTful API:

Missing pieces and challenges

I had hopes of hooking into the existing set of endpoints, being able to reuse much of the utility code and structure. This was not possible, as there is no apparent way to extend the WooCommerce RESTful API gracefully.

Product listings

We could have used WP JSON API operations here, as Products are a custom post type, but direct use of the WooCommerce interface was going to be both more informative for the app, and less overall work as far as grabbing all the additional fields like price and tax information.

Shopping Cart operations

The WooCommerce API provides an interface for its Orders, but that’s the tip of the order-processing iceberg, and we needed the rest of it. Since the app only deals with a fraction of the information that a browser-to-server transaction deals with, that is, there are no browser cookies involved, there were some subtle problems for which I had to make workarounds.

Payment methods

The project required use of a particular payment gateway so I had to create code to accommodate that:  a general-purpose implementation of WooCommerce’s gateways API via a RESTful service. Examples of ad hoc workarounds include having to force PHP’s $_POST array to have required values, or hard-coding which input parameters are required for registering payment methods.

Checkout process

As a programming ideal, it’s good to have a singular purpose for each piece of code, and this ideal was not found in the WooCommerce checkout routines. Every step of the checkout process had provisions for user account registration, something which I had to work around. I also ran into a problem with the checkout procedure silently failing, where its built-in error checking was not triggering, leading me to have to duplicate the steps it took in the API endpoint interface I wrote.

Shipping methods

Coding a RESTful API to interface with WooCommerce’s shipping methods classes involved having to make artificial restrictions in what we could code around. Session handling and the lack of cookies served to be a source of frustration here too, resulting in odd interactions between shipping methods.

Conclusion

In no way is this post intended to “bash” WooCommerce. We at Zeek feel they have created a fantastic product and we use it with many of our clients. Now that WooCommerce’s parent company has joined Automattic, we’re hopeful that some of these gaps in the WooCommerce API will be filled in and documented. I’m proud of the work I did extending and customizing the API, but a more robust interface for mobile will make the job much easier for future developers and ensure WooCommerce and WordPress become more widely adopted key tools in mobile development. I am happy to share my findings with the WooCommerce team. Hit me up!