/

May 9, 2023

Unlocking Your Options: How we Reverse Engineered Web APIs to Avoid Vendor Lock-In

Context

Our healthcare client operates wellness clinics in multiple locations and offers a service that assesses and prescribes exercises based on patient’s needs. The service uses a machine that measures muscle strength and sends data to a centralized web app for analysis and reporting.

The client learned that the exercise machines that are being used are close to end-of-life, and the web application will be deprecated soon. However, the replacement of all the machines across 20 centers would be an expensive affair. 

The exercise machines are still in good working condition and serve the purpose of providing muscle strength data. As a result, the client sought to replace the web application with integration into their ERP system to continue to leverage the existing exercise machines.

Problem statement

Can we integrate the exercise equipment with the customer’s ERP system and display the data there, replacing the legacy web application? We need to ensure that the current usage is not disrupted during the integration process since the machines and the legacy web application are constantly used.

Solution

To achieve this, we analyzed the network traffic generated by the machines. The machines could be configured to send data to a configured web service on the backend.

In order to build a solution that allows the data format generated by the machines to be consumed by the ERP, the following steps are required.

  1. Capture the traffic generated by the machines and log the interactions. This has to be done while the data is being sent to the existing legacy system.
  2. Analyze the generated data and define the API interface to be built.
  3. Build an ERP Service API that implements the API interface and responds with the expected interactions so the machine can continue working as usual, but the backend API can now be connected to the ERP database.
  4. Once tested, reconfigure the machines to send data to the ERP service now.

Our analysis led us to propose a solution: a proxy server that captures machine-sent data and leverages it to generate necessary data analysis and visualization. With this method, we can integrate the exercise equipment with the client’s ERP software by mapping user details to ERP system users.

Building the solution

There are many open-source proxy server applications available, we picked NGINX for our solution. By default the proxy server logs HTTP calls, but only the request URL, client IP, timestamp, etc. The real challenge was to log the request payload. To solve this problem, our solution was to use NGINX with the ngx_echo plugin. 

The ngx_echo module is suitable for our use case, but it is not distributed with the Nginx source, so we need to install it separately. Fortunately, we found OpenResty, which is a web platform built on top of Nginx and comes with the ngx_echo plugin pre-installed. Therefore, we chose to use the OpenResty flavor of Nginx to log requests using the reverse proxy.

See Appendix A:  “Capturing the data” to learn how to configure OpenResty.

Using the log files generated by OpenResty, we were able to examine the interactions between the exercise machines and the legacy web application. Once we understood the flow of communication and data formats, we were able to build an API interface that mimicked the original web app to intercept this communication. 

Once the new solution is tested and certified, we can just replace the OpenResty URL with the URL to our application, which will now act as a drop-in replacement for the legacy web application.

Conclusion

Using OpenResty and Nginx, we were able to provide a solution to our client that allowed the continuing use of the exercise machines they had invested in already, resulting in significant cost savings potential.

At Indexnine Technologies, we solve problems like this every day for our customers. Let’s discuss your requirements. Get in touch.

Appendix A: Capturing the Data

Instructions for Installing OpenResty on Windows

  1. OpenResty for Windows can be downloaded from the official website at the following link: https://openresty.org/en/download.html 
  2. Once downloaded, unzip the package to access OpenResty.

Configuring a Reverse Proxy for OpenResty (Nginx)

The reverse proxy works the same as Nginx in OpenResty. To configure the reverse proxy, paste the code snippet below under the ‘http’ block in the ‘conf/nginx.conf’ file.

http {
    
    log_format bodylog escape=json '[$time_local] || '
      ' METHOD: $echo_request_method || ACTUAL_URL: $remote_host/$request_uri || QUERY_STRING: $query_string || STATUS: $status ||'
      'REQ_REFERER: $http_referer || REQ_TIME: $request_time || '
      'REQ_BODY: $request_body || RES_BODY: $resp_body || REQ_HEADERS: $echo_client_request_headers';


    lua_need_request_body on;


    server {
       listen  80;
       listen  [::]:80;   
       
       set $resp_body "";
        body_filter_by_lua '
            local resp_body = string.sub(ngx.arg[1], 1, 1000)
            ngx.ctx.buffered = (ngx.ctx.buffered or "") .. resp_body
            if ngx.arg[2] then
                ngx.var.resp_body = ngx.ctx.buffered
            end
        ';


        set $remote_host "http://127.0.0.1:3000";


       location / {
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header Host $http_host;
            proxy_pass $remote_host;
            access_log  /logs/http-proxy.log bodylog;
       }
    }
}

Here, we have configured a reverse proxy on port 80 of our machine to point to http://127.0.0.1:3000. This reverse proxy captures the standard access_log using the custom log format that we have defined in the ‘log_format’ variable.

You can find the access logs in the ‘logs/http-proxy.log’ file in the root directory of your OpenResty installation.

Start OpenResty (Nginx)

  1. Start Nginx (nginx.exe is located at the root of openresty setup)- start nginx.exe
  2. Stop Nginx- nginx.exe -s stop
  3. Target server/website can be accessed on http://localhost

You can view the access logs by making a request to localhost on port 80. The log files are updated in real-time as requests are made.

References

OpenResty
Nginx
Nginx Echo