But why is that needed?
Recently in 2466, Vlad already enhanced the Base URL (a feature pushed by a few of us) because it used to force a ? in between the URL and a parameter.
Using a simple REST service that allowed URL encoding, this sufficed. If you needed to build a simple string like:
xxx.url/api/v1?custid=1&invoice=1001
then aware did that from the start. But, some services needed this:
xxx.url/api/v1/lists/1001/members
In this case, if you put lists/1001/members in a parameter variable, then aware would send this:
xxx.url/api/v1?lists/1001/members
which would be invalid.
So, the 2466 fix allowed you to start your parameter with a "/" and then aware would NOT insert the ? resulting in this:
Base URL = xxx.url/api/v1
parameter = /lists/1001/members
Aware sends: xxx.url/api/v1/lists/1001/members
This would work perfectly for a GET and data would be returned just fine.
BUT WHAT ABOUT A POST?
Using my example, MailChimp, you use the exact same URL for a GET and a POST.
But the POST needs to send the data in a JSON string.
This caused a problem because now you need 2 variables...
one for the BASE URL, because the LIST ID that you want to add a member to is part of the URL,
and the 2nd parm is the JSON string.
WHY? You need your REST service to be dynamic. So you have to calc. your BaseURL to insert the appropriate CustID, or Invoice#, etc. We can now build this in Process before REQUESTing the service.
Code: Select all
LoggedInRegularUser.TempRESTBaseURL = 'https://us18.api.mailchimp.com/3.0/lists/' + MC_lists.listid + '/members'
Thankfully, the latest build 2467 essentially allows for 2 variables... 1 in the URL, 1 as the Parm string. (see above image).
This worked perfect on my 1st attempt posting members into a list in MailChimp.
--> JaymerTip