I’m not getting any problem deserializing the response so I think there may be something else causing the issue. I, too, am getting no errors in validating the JSON response.
First search is for “Fr”, then “Fre”, then “French” all deserialize without error. I’m using Newtonsoft.Json which I think SambaPOS uses as that library is found in the app directory.
OK, Solved…
Its web.Download() thats the issue.
Change to web.PostData() with null data and works fine.
function test(search){
var url = "https://www.thecocktaildb.com/api/json/v1/1/search.php?s="+search;
var json = web.PostData(url,'');
var data = JSON.parse(json);
return json
}Sorry I should have spotted that. Yes you need to use the post if you are sending JSON formatted data.
Although saying that, its probably not a function meant for grabbing raw code, its pulling the rendered version id guess so things that are esscapes will be rendered as they would on screen,
As jessie already confirmed.
Have changed to question rather than issue…
Thanks for the help. This is my first attempt at using an API, so I appreciate you helping me through it.
I didnt even think about the function after seeing aparent data issues…
Have never used web.download, always postdata as a habit from the PMS setup
I’m inclined to think it’s still an issue. Use of web.Download() for GET method in this instance makes sense. web.PostData(), though it works, seems like it should only be used when POST method is required.
I feel all the web.x methods should be returning the response content unadulterated.
Even if it’s an HTML page that’s returned, the response content should be no different than pulling it via wget or viewing source in the browser.
I get what your saying but personally I would expect download to be more like a post render scrape rather than an api interface tool and that perhaps there should be a web.GetData().
Never really looked into if there is a difference between GET and POST other than the included data rather than just url in which case null data is same thing…
It depends on the endpoint. Some APIs will balk at POST data coming in when the method requested is GET regardless of the URI.
It also seems that for the Download() method the encoding is hard-coded to UTF-8 so that may be causing some of the issues with the umlauts, uzw. PostData() and PostJson() don’t have any encoding specified.
So it mostly has to do with when and why we developed the methods.
Short story they were developed separately for two different reasons and are not actually related. Web.download was first and is very limited.
No sure I’ll use this feature since the drink DB seems to be a little weak with recipes, but I liked the idea of giving our bartenders the option for a drink recipe if they don’t know it. It might even be better to do your own recipes with custom data. Some features I wanted to use:
I would need to mess with formatting and add some wait time for the query it looks like, but overall it works.
Joe
@josephrussell look at putting web widget in ask question format, could show actual page for recipe if proffered.
Thats not a bad idea. I actually like the idea of storing our drink recipes since ours are often custom and bartenders do make up their own drinks.
@josephrussell
To reduce custom fields you could store json within a custom field for recipe,
Or nothing says has to be all one site, you could do web popup with url from custom field for any recipe site for each product seperatly.
I imagine we could just store it in two fields for image url and recipe. Just put he recipe in a single line of text.
Tried the web widget. Load time is longer for sure, likely not the best solution. This is all more of a general concept then something I plan to immediately use. I did see another API which has a ton more recipes, but its not free.
Thanks.
