I am able to read the barocode but i am confused about how to get the food product value from the barcode value .
Do we need to call a webservice or create a database locally ...
help me out
thanks in advance
Have a look at OpenFoodFacts. It's a database that does just that, with ingredients, calories, etc. It's based on the barcode.
Product bar-codes contain almost no product related information - they are mere unique identifiers. The system used in Europe - EAN13 - consists of a country code, a manufacturer code, a product code, and a check digit. To translate any of this data into usable information you need a database or web-service.
I know this was asked a long time ago but I figured I would give an update for anyone looking now... We use an API called upcFood (www.upcfood.com) They offer a simple API that allows lookup of food products directly from the barcode. upcFood includes nutrition data, Products Data, allergy data, ingredients etc. from a single search.
In case anyone else is looking for this info in 2021, you can get this data directly from the USDA's Food Data Central API, which is public domain. One of their endpoints has a query param, which supports keywords and, as a little tinkering revealed, UPCs! For instance, here's a query for a snack I had laying around:
https://api.nal.usda.gov/fdc/v1/foods/search?query=850126007120&pageSize=10&api_key=DEMO_KEY
API keys can be had with an email address. Hope this is useful to someone!
Free database here:
http://www.upcdatabase.com
and here:
http://www.yoopsie.com/
Otherwise just Google for "upc database" and you'll find people offering to sell you one.
I doubt that the databases will include prices since those are for the individual retailers to set.
I am not sure if you still need the information since it is dated a year..
A french startup has created an application that can find most of the correspondant of ean-code to food product. It provides as well an API for developper to integrate in their application.
You can check it at : http://prixing.fr/api
Since it is based in France, it is in French language .. if it is useful, I hope it can help
Related
I am creating an App which needs data for countries, states and cities which is available at lots of places but here for some reason I need to know the latitude and longitude of each country including its state and city. From which one source can I find all these? I need to store this data in mongoDb.
I tried downloading allCountries.zip file from here GeoNames but I found that data is not in proper tsv format and it's very complicated to get the expected output data from here.
Is there anything else from which I can get the desired result?
Please help if anyone knows
Thanks a lot in advance :)
There is a webservice provided by geoNames which gives all the information about countries, states and cities.
http://ws.geonames.org/childrenJSON?geonameId=8505026&username=demo
this is an API which gives children i.e if you provide countries geonameId then it will give its states. If you provide states geonameId it will give its cities.
So in that way we can have all the information about countries states and cities. To get all geonameId of countries for that they have provided another API
http://api.geonames.org/countryInfoCSV?username=demo
There is just one thing we should keep in mind that for username we have to create an account and whose credit limit is approx 2000 per day. So if we want to hit the API more than 2000 a day we have to create another account :)
Pretty good thing and very useful thing provided by geoNames
I am designing a REST API for my service and am trying to decide how much data should be returned about a resource, when an ID isn't specified, For example purposes, let's pretend the API is for a library.
While I am happy for GET library/books/283765 to return all the information about this specific book, I am less certain on what GET library/books should return.
At a minimum I would expect to see a complete list of book IDs. I might be tempted to accompany each ID with the book's title, maybe also the author. As I know this is a large library, I would be surprised to see all the information about every single book (Publisher, Year, ISBN, Blurb etc). Is this something REST has an opinion about?
If not, would it be bad design when describing another set of resources, to return more or less data?
Lets pretend GET library/rooms lists IDs for all the rooms in the library. But in this case, the only property a room has is Name. If GET library/books only returns book IDs, then surely I should follow the same rule for GET library/rooms, even if it seems inefficient in this case.
Perhaps the answer is return the minimum amount of data about each resource, that a user might want to know? This would potentially prevent thousands of GET requests, or one extremely large one. The hard thing of course is trying to decide what the minimum amount of data actually is.
Any thoughts?
Is this something REST has an opinion about?
REST has no opinions on how URLs should be formulated.
If not, would it be bad design when describing another set of resources, to return more or less data?
It is expected that different resource collections will have different detail levels of data available by default.
Perhaps the answer is return the minimum amount of data about each resource, that a user might want to know?
That is the goal. More specifically, the appropriate amount of data for somebody looking at the collection. Users seeking more detail will have to follow the URL to the individual resource (book, room, etc) to learn details like print run number or floor color.
You as the developer have to pick the set of default information for each collection endpoint. Check with some potential end users and see what they expect. At a minimum, probably a link to the item, id, title, and author for a book, but it really depends on what your users intend to do with it. Perhaps you're writing a system for librarians, in which case the Dewey Decimal number might be top-level information.
I have not experience with Rest services, but i think as a general rule, you should return what the user really need in most of the cases. In case some user need extra data about a book should query que service for the specific book ID to get it.
If you think that your database will be too big for sending for instance a colection of books, you got other options, like asyncronic returns or paginate the service result. In the last case the service will return only 100 books per page. So if the book the user is searching is not in the list, he will ask for the next page.
Also i would advice you to force at least one filter to narrow down the list of books. Think that is not logical from the user point of view to navigate a list of say 10000 books for a specific one. Hope it helps you.
https://developer.intuit.com/docs/0020_customeraccountdata/0005_service_features/0050_categorization
The schedule_c_categories listed here seems out of date. I see a lot more categories in my data than what is listed here.
For example, in my data, I see "Other Business Expenses", "Deductible Meals", etc...
Is there a more complete list of all schedule_c_categories intuit uses?
Also, while we are at it, is the regular category and sub-category list complete?
Thanks.
Please submit a support ticket - https://developer.intuit.com/Support/Incident
I want user to select city during filling his profile. What is the best way to do it in web application?
I there any other way than just store a list of cities in my DB. Maybe some public API?
The best way to do this is with a big database, unless you want to allow the user to type in a city name.
Fortunately for you, you don't have to go out and make the database yourself. Here's a directory of free databases: http://www.sqldumpster.com/databases/geographic/
I'd just go with a simple text field with an auto-completer. You can get a list of cities but you'll have to keep it up to date and you'll have to worry about nonsense like the difference between "Saint John", "St John", and "St. John".
Sending an entire list of cities to the client will just be a user interface nightmare, a selection list would have thousands and thousands of entries and you'd have to send a lot of data to the client; there's no reason to hate your visitors that much.
The auto-completer can use the currently chosen cities to provide suggestions for new cities. If you have city names in several places, then just keep a master city list somewhere for the auto-completer and updated it with new entries every day. You will end up with a list of cities but the list will build itself.
A simple text input will work the same everywhere and just about everyone can type out the name of their city pretty easily.
You could store them in a text file, have a copy in your server (for validation), and load the cities via AJAX.
That approach will break, however, for users without JS.
And, to be snobby, can you define best? Best in what sense? Fastest? Lightest? Awesomest? Most Pythonic? I'm not sure what you mean by that.
Given that we provide a restful api that serves book entities listening at
/books
And a client can get a book at the usual
GET /books/{id}
Suppose that we want to begin offering discounts on books to only our most vigilant buyers. These buyers would be given a discount code, and that code will reduce the price of the book.
Thus, a generic response may be
GET /books/4
{"id":4, "price":"24.95"}
Where a response to a query with a discount code may be
GET /books/4
{"id":4, "price":"24.95", "yourPrice":"19.95"}
The back-end processing we can get figured out, but what is the best practice for a client submitting a discount code over a restful api?
Certain books will be eligible for discounts while others will not. Discounts will not be broad (20% off everything), but instead will map to a specific price for that particular code (or client/code combo).
We've considered:
kludging the url
GET /codes/{someCode}/books/{id}
Adding the code in a header value
Using a query string
GET /books?code=myCode
anything else?
EDIT: Our goal is not to implement single-use codes. Instead, these discount codes could be used some fixed number of times for some fixed set of books.
I like using query variables. I just looked at the RESTful Web Services book, my main reference in this area, and they say:
Use query variables only to suggest
arguments being plugged into an
algorithm... If two URIs differ only
in their query variables, it implies
they're the different sets of inputs
into the same underlying algorithm.
It seems to me your discount codes are inputs to a discounting algorithm.
Charles
If you're going to be submitting anything that's not idempotent, I would suggest using POST instead of GET. You wouldn't want a client to be able to use their code more than once.
Anything you add in the URL or header values are open to be intercepted, and possibly allowing other users to 'fake' their discount ID. 1 approach would be to introduce a new POST call, that will allow the ID to be encrypted with simple HTTPS. The POSTed data could be as simple as the discountID or customerID.
Added - Sorry Michael, you already said that :)
You can register the code in a table so when the user retrieves that book automatically returns that book with the proper discount, for example:
The user can add some code
POST /register/{code}
This will add an entry to a table {user} - {code} so when the user retrieves by
GET /books/{id}
will use that entry to apply the discount. I'm guessing that you already have some relation between {code}-{book} so wont get into that.