Closed everycook closed 9 years ago
This one needs a bit of thought first. Why not have an overall "parameters"-call, which you send at the beginning and it gives you the available parameters for the search api call? We also have rec_type as input for the search api where a third party would also first have to get the available options. And then the return should be for each of the parameters a list with the name in the desired language plus the ID. on a side note, image urls are perfect example for what will later probably be a premium feature and not accessible with free api.
Good suggestion. Let's call the API /searchparams and so it can grow with its future requirements. with no option you get a full array of the variables available to limit search. but you can also call a list of each one (like cuisine) by adding the "cuisine" option.
please put in on the production system
Having an option to send type=all_cuisine resulting in an answer having the whole cuisine/subcuisine/subsubcuisine tree would be great.
now for "all" categories/types that have subTypes you can add the param "tree=1" and it will return the tree of data down from selected type: example link on test: http://www.everycook.org/db_wsd/api/searchCategories?token=everycook&type=rec_cuisine&tree=1
currently filtering data when using tree option is NOT possible, it will always show all data.
We need a way to get a list of all cuisine types and subtypes with IDs. So we can use the IDs to filter in the recipe search.
Input Variables: Lang: mandatory Cuisine type: optional (all if not selected) Sub_Cuisine type: optional (all if not selected)
Output: List of cuisines with sub and subsub cuisines if not narrowed by optional input variables. With img_url of course.