A client has asked me to add integration with a 3rd party service to an existing VFP application. The 3rd party service operates a sales website and has provided an SDK for communicating with the site.

I'm testing using wwIPStuff in between VFP and the site. The SDK operates from POSTs and the first call I tried worked just as I'd hoped and gave me a JSON result that I can parse and work with.

But the main thing I need to do is call on this site to actually display a subset of products and let the user shop. When I POST the call to start that process, what I get back is HTML with JavaScript.

I'm trying to figure out what to do with that result. I tried saving it as a file and and using Navigate2 in a WebBrowser control, but I get script errors and nothing appears in the control.

I've never done anything like this before and I feel like I'm missing a key piece of the equation.

Thanks Tamar

Make sure the HTTP endpoint (Url) you are hitting is actually an API endpoint that returns JSON. If that's not it find the documentation and look closely at what the service is asking for input.

A few things that come to mind:

• Make sure if you post data to the service you set the Content-Type (json is application-json)
• Do you need authentication? The HTML you see may be their login page because you're not authenticated.
• Do you need to pass some sort of Auth token?

When working with API endpoints I always recommend you test it outside of code first. You can use a tool like:

• Postman
• West Wind Web Surge

To hit the URL with the data and tweak it interactively with these tools until you get it working there. This removes the code angle from the HTTP request and lets you look at raw data that is sent and you then duplicate with the FoxPro code.

If you're new to all this I recommend you take a look at my Virtual FoxFest session and white paper from last year:

• Building and Consuming REST API Services with FoxPro

The first section is an introduction on the HTTP aspects you're asking about here, and the second part walks through how to call JSON APIs sending and retrieving data.

Hope this helps,

+++ Rick ---

Thanks, Rick. Your paper helped solidify my understanding of the concepts here.

In this case, the API really is giving me back HTML. According to the 3rd party folks, I should "open it up in an iFrame or any browser supported window."

Reading their documentation more carefully, what they're actually saying is that my application should open an iframe and then call the relevant URL. The HTML will be displayed in the iframe and when the user clicks a button, the results returned to the application.

Is that something I can do with the Web Browser control or in some other way from VFP?

Just to help make more sense here, my client has a vertical for auto repair shops. The 3rd party is a parts supplier. The idea is that my client's customers should be able to find and order the parts they need through the vertical, passing info from the app like the year, make, and model of the car, and getting the results back in a form that allows the parts to go right onto the invoice for the car owner. If I can get this part worked out, I'm pretty sure I can handle the rest.

Tamar

I'm going to say that if the 'API' is returning HTML, it's not really an API, but just an HTML based Web application and you're hitting a Web Url. I know this is mostly semantics, but it completely changes of how you need to interact with the URL.

• An API returns Data
• A Web application returns HTML

In some rare instances APIs also return HTML, but that's usually for very specific usage scenarios.

If this is a Web application that lets you access certain URLs and return HTML, then you need to take a look and see what is actually returned.

• Is this self-contained HTML?
  ie. all the links and dependencies are fixed and work if you render it on your own

• Can you simply access the URL directly?
  Can you simply point at the target URL, pass the appropriate URL parameters, and use the result directly from their site in an <IFRAME> or separate browser window/tab.

It rarely makes sense to use an HTTP client (ie. wwHttp) to call an API endpoint to retrieve HTML, only to then display it in a browser later as that only complicates things as you need to deal with fixing up the document dependencies (css, js, images etc.). In that case it's much easier to just have the browser navigate there directly and then display the content in the browser (or IFRAME or external Window/Tab). However, that depends on what needs to be passed in to access the URL and whether you can pass that from a browser directly.

+++ Rick ---

As I read this documentation and the other info I've been given, this seems to be part API and part web app. I think what I'm supposed to be doing here is:

• POSTing a query to get the URL of a service. I've got that working.
• Navigating to that URL (with a bunch of parameters) in an iFrame. (Just tested and if I assemble a URL with the parameters and paste it into a browser, it opens and behaves as expected.)
• When the user clicks a particular button, data is supposed to be returned to my application in JSON format.

So I guess my question now is how I do the second and third parts from a VFP application.

Can I (and do I want to) use the web browser control to navigate to this URL? (First attempt is giving me javascript errors that I'm pretty sure are related to scope.) If not the web browser control, am I'm looking at EXECSCRIPT() to use whatever browser is default?

What kind of mechanism will let me receive the response from the webpage when the user clicks the appropriate button?

These feel like really big questions, so feel free to point me at more reading.

Thanks, Tamar

You can't get data returned to your application from a Web page, unless you are hosting the Web page in your application (ie. via WebBrowser control or something similar). There's no way for the Web page to call you back since you are a just a client calling the server or a user browsing inside of a Web page - there's nothing connecting the two.

In a typical API you call an endpoint on the server, and it returns something to you as part of the same request - sounds like that's what's happening with the POST to retrieve the URL.

There must be something else happening for them to be able to do this:

'When the user clicks a particular button, data is supposed to be returned to my application in JSON format'

Something is missing here.

It seems to me this may be intended as a Web API to be hosted inside of a Web application via JavaScript where there might be some communication between the host page and the IFRAME or events firing in app, but otherwise this doesn't make sense without a lot more information on they are 'passing the data back to you as JSON'.

+++ Rick ---

Thanks. Sounds like it's time for me to go back to the 3rd party vendor and see if I can get more information.

Tamar

Hi Tamar,

I was just reading this thread and thought I would chime in. I built an auto parts SaaS platform using WWWC that is still active 20+ years ago. It sounds to me like the 'supplier' who has the catalog of content does not have an api, but rather a 'punch out catalog' as they like to call them. The integration with an iframe is intended to be 'api-free' in that, you have no access to the raw data (by design) and you are supposed to rely on the suppliers UI. Often times they let you customize the buy button in their 'hosted' aka 'punch out' catalog so that you can integrate the products into your local website.

If it happens to be auto parts, you can give me a ring sometime Wednesday if you'd like.

Cheers,

Michael B

Yes, it's auto parts and I've made some progress and gone back to the supplier with additional questions.

Thanks for the offer. I may take you up on it, though probably not today. (Guessing Michael B. is Mike Babcock?)

Tamar

Michael Birnholz - My company is sophio.com. You can check out an active site here - https://www.pastorepickup.com/catalog-2/

This is a bit slow because it uses real time price and availability against a backend that has some middleware between the WWWC app and itself.

This site you see uses a json api to get parts and inventory pricing content. This is something I could offer your client btw (building a custom catalog api so that you could build your own app that consumes it if you wanted too). We have thousands of brands and close to a BILLION fitments (meaning, the millions of items for the thousands of brands 'fit' close to a billion diff vehicle combinations.