Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 6 years ago.
Improve this question
I am using the API to GET and FETCH data from my 150 or so Google surveys.
For some surveys I find the FETCH works OK but the GET is rejected with error 503. For instance:
HttpError 503 when requesting https://www.googleapis.com/consumersurveys/v2/surveys/6mndemyqw5b5k?alt=json returned "Survey is configured in a way not supported by the API, i.e. contains unsupported question types or options Request Id: 5750b15c00ff025d5da8b9f4b00001737e3430322d747269616c320001707573682d30362d30322d7231330001010a
The surveys are nearly all one single response questions and were created with the web interface. The common factor I notice is that the failing surveys I have looked at all contain an answer with a non-Latin character, e.g. Siân Berry (Green).
Whatever the reason, this is quite a problem because the GET operation is the only one that returns a full list of answers in the originally specified order.
Also, the question text itself is only otherwise available by scraping the Overview sheet of the exported XLS file. I say scraping because so far as I can tell the spreadsheet format is neither documented nor stable - for instance the response data used to be in worksheet "1" but more recently seem to be in worksheet "Complete responses".
This issue has been resolved. We'll new return the UK 'country' in the 'audience.countrySubdivision' for those surveys.
The cause was that for a few countries (US, CA, UK) the GCS UI allows surveys to be targeted by macro-region (e.g. US-WEST, CA-PRAIRIES, UK-ENGLAND) in addition to state (US), province(CA), or Nuts-1 region (UK) which are targeted in the API via the 'audience.countrySubdivision' property.
To provide a consistent API across all countries, we do not offer macro-region targeting in the API and that will not change with this fix. However, to allow you to access your data which was created that way through the UI we will now return Surveys that are targeted to macro-regions by putting the region into the 'audience.countrySubdivision' property.
Thanks for reaching out. It appears that the surveys that are failing are all targeted to the UK-England region and have root caused the underlying issue which has to do with NUTS 1 region codes. We'll work on getting a fix out asap.
Related
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 months ago.
Improve this question
How does spy tools like Ali-hunter and ppspy get data from Shopify stores, normally in order to get this data you'll need to use a webhook, but this only applies to your store and stores that installed your application.
PPSPY does the following.
It reads your Shopify sitemap to find the products in the store.
.../sitemap_products_1.xml
As fallback, it parses the URL:
.../collections/all?sort_by=best-selling - and tries
to find the products there.
Next, it uses the JSON URL from Shopify. There again it tries to find
all products. An example URL:
.../products.json?page=1&limit=250 - most store owners don't even know this exists.
After that, it calls the JSON URL for each product. You can get this
URL in your online store by simply opening a product page and writing
".json" after it in the URL. Example URL:
.../products/your-productname.json.
In this JSON there is a field "updated_at". This field is updated every time a change is made. Also, when an order take place (the stock is changed).
And with this, it is possible to track the sales (approximately).
They are called web scraper or crawlers. They go to your product page (going through all the links in your ecommerce) and understand the content of the page. They extract the product name and the product price. They will do that every X hours or X days and collect the information, so they don't need any webhook.
In theory you could make your page complicated enough to not make it easy to crawl, for example you could show the price with Javascript (the crawlers typically have javascript not enabled). But that would make your website less accessible, especially to Google, which is in fact another crawler.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
I'm looking into using the findCompletedItems API request to look up historical prices on sold items. In the documentation (https://developer.ebay.com/devzone/finding/callref/findCompletedItems.html) it specifically states that you are limited to 5000 requests per day, which is fine, but it also says that you are not allowed to store the data, which makes this more difficult.
"Be aware that it is possible to use this call in such a way as to
violate the terms and conditions of your API License Agreement. Ensure
that you do not store the results retrieved from this call or use the
results for market research purposes."
Our purposes of using this data is to draw traffic to our application, which would then in turn direct traffic to eBay using our referral links, but if we have to make this request every time a user looks at a particular item then it's not going to be plausible as we'll make way more then 5000 requests a day and even if we qualified for the elevated api request limits 1.5 million would still not cut it on top of slowing down the application considerably because we can't store any data.
So I'm just wondering what eBay technically considers "storing data". Can we cache the data for 48hrs or something along those lines?
Thanks!
I don't have a definitive answer for you, but I would imagine that caching the data for a limited time would be acceptable. If you respect their API, the eBay Dev staff are very reasonable people to work with.
I suspect their prohibition of storing data is meant for longer-term API-scraping and warehousing of data meant for deep post-analysis/research/etc.
Also, know that even if you get approved for 1.5M calls per day, that doesn't apply to the findCompletedItems (fCI) call (and only applies to the other Finding API calls), and you're still limited to 5K/day on fCI.
You speak of needing to display info about specific items. Remember, you can use GetSingleItem or GetMultipleItems from the Shopping API (1.5M calls/day, if approved) to get specific item info, including ended items. No need to use precious calls to fCI to get item specific info.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have looked at many articles regarding REST and its design implementation for an API. I have a couple of questions however, and maybe they are simply opinionated as there is no "one fits all solution" to REST or API development in general.
Note that these questions are in regards to contacting and receiving requests from an SDK.
My questions are both in regards to the URI form, as I believe it is called. I have seen this represented in a few ways, but my big concern is about versioning and "dynamic" sections.
For my first question (version'ing) I have seen the following approached used often.
/customers/accounts/V3.4/customer_id/1234
/customers/accounts/V3.5/customer_id/1234
Developers would implement this by keeping a general version class, and as they make calls it would grab whatever version the developer has setup. So if they ever wanted to move up to a new API version they would just have to modify the V#.# in one location. I am wondering how good of an this idea is in practice, especially for an SDK. My general thoughts are that this is OK. I believe this as versions are clearly pointed out. If a change needs to be made it is simply a matter of updating your version's call. With an SDK in mind, using an old API won't break anything as if they do not update for awhile then their API request will still be fine, but will route through an older endpoint.
Question 1. Is version'ing using the approach above okay for API updates? Pro's/Cons?
The second question about dynamic values can be seen as follows.
/customers/V4.3/{customer_id}/account
versus
/customers/accounts/V3.4/customer_id/1234
I am not sure if there is a better trade-off to having dynamic endpoints versus hard coding them as listed above. I say this because what if we have a scenario where we wish to add details to the "account" page.
In the above example customers/V4.3 would not have to be updated, as it still contains the same user list midpoint. We would be able to update the account API without causing a version change. (forgive me if that is a terrible idea). But with the second option we would have to update the versioning as that is a midpoint
Question 2. In the example above, is it better to focus on more static or dynamic endpoints?
Still very new to learning about this, forgive me if I made some bad assumptions or conclusions on API design.
What is the problem with using Parameters ?
IMHO
Things that are dynamic or can change in future should never be part of the URL path.
This is why parameters exists. And the benefit is :-
http://example.com/api/resource/?customer_id=1234&v=3.4
Would be treated the same by your script as:-
http://example.com/api/resource/?v=3.4&customer_id=1234
I don't know the context of the SDK, but I would think hard about requirements before allowing API users to choose the version & perform actions.
Also please take a look https://stackoverflow.com/a/17999251/2489860
This is one of those RESTful debates that can go round in circles. You have three options for specifying the version: the URL, the content type or a custom header. All of them will be considered "wrong" by some folks.
Troy Hunt's written a pretty good discussion around the pros and cons here:
http://www.troyhunt.com/2014/02/your-api-versioning-is-wrong-which-is.html
However, I wouldn't necessarily be too quick to reach for versioning as a solution. You may want to consider side-stepping the issue by using more tolerant consumers, investing in more up-front design or applying the open/closed principle to your APIs.
This argument is expressed in more detail here:
http://martinfowler.com/articles/enterpriseREST.html#versioning
It includes a great quote:
"Some people, when confronted with a problem, think "I know, I'll use versioning." Now they have 2.1.0 problems."
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Yahoo! Finance feeds are pain in the ass.
Google Finance API seems OK but don't know why I can't retrieve stock quotes information for Dow Johnes, NASDAQ, S&P...
Works perfect with company quotes like YHOO, MSFT but don't gets full data for stock indexes.
There is an article at YQL blog on how to get this data from Open tables with YQL, but that table is missing in the list.
Can anybody recommend any good API, web service or a feed?
Best answer + vote up guaranteed.
Yahoo provides a free API via http. You can get real-time informations & historical data in csv format.
For example to get the S&P historical data (^GSPC):
http://ichart.finance.yahoo.com/table.csv?s=^GSPC&ignore=.csv
or Dow Jones (^DJI):
http://ichart.finance.yahoo.com/table.csv?s=^DJI&ignore=.csv
URL syntax explained at:
http://www.gummy-stuff.org/Yahoo-data.htm
You can also use YahooAPIs and send a YQL query that returns an XML document, such as:
http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20yahoo.finance.quotes%20where%20symbol%20in%20%28%22GLD,SLV%22%29&env=store://datatables.org/alltableswithkeys
To make things easier, I wrote a simple YahooFinanceAPI script on GitHub. Example usage:
$y = new YahooFinanceAPI;
$y->api(array('SLV','GLD'));
For more complete information you can view an article I wrote at http://thesimplesynthesis.com/article/finance-apis/.
Nordnet External API looks good:
Nice documentation although more sample/boilerplate code would be good.
Support forum with some activity.
Development environment where you can play around.
Before you can use your application for actual trades there is a certification process to ensure that your code works.
The API is for building trading bots and not for downloading price histories though.
Could it be that you're using the wrong symbols for the averages? For example, the symbol for the Dow Jones Industrial Average is .DJI - something that caused me a bit of confusion when I was searching for it. The symbol for the S&P 500 is .INX, which is even more counterintuitive.
Take a look at the Interactive Brokers API. Among many other features, it has delayed and real time quotes available via the API.
http://www.interactivebrokers.com/en/p.php?f=programInterface
Take a look at http://www.mergent.com/servius (no stock quotes, but lots of other financial information like dividends, corporate actions and financial statements)
#Brian: The delayed quotes are NOT available through the IB API at the time of writing. Only the real time quotes - and those are not free.
See http://ibkb.interactivebrokers.com/taxonomy/term/147
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm hoping this question isn't too obscure cross fingers
I'm looking for a decent reference for netsuite scripting and api (both of which are based on ASP)
does anybody know where to find this stuff? The netsuite help pages are mediocre at best, and the forums aren't very active. (I suppose these two things are already bad signs, but it's worth a try right?)
As a ex NetSuite employee I was frustrated by this time and time again, even internally there is no good refs other than the published pdf's in dev docs.
One of the best places for snippets of code and clues of how to do things is the NS User Groups as well as the not so good sample apps.
A lot of it is done with trial and error. I have found developing web services a little lest frustrating than the client and server side scripting.
B
Found some sample code + documentation here. I integrate netsuite with some kohana based site. I've thrown up two snippets that I use for easing development, a getNetsuiteConnection() method and a snippet used for getting a list of custom fields in a given record.
Update:
Found some more resources recently (mostly targeted at using NetSuite via the PHP framework).
NetSuite Global Scope Problem
Getting a List of Customers
NetSuite Tips & Tricks
Tips & Code Samples
08/12 Update: If you are working with ruby, checkout this gem which implements a portion of the NetSuite SOAP API.
A Quick Netsuite Scripting Tip
When working on SuiteScript, we have different field types and and form fields in NetSuite but to get values from these we have generic functions
nlapiGetFieldValue();
record.getFieldValue();
rec.getValue();
These functions always return values as type string. Even for Date and Numeric type of fields.
So when manipulating values returned one should(have to) convert them to right types to avoid bugs.
For example we may apply parseInt or parseFloat for Numeric data.
var val = nlapiGetFieldValue('fieldId');
if( 3 > parseInt(val))
Beware that ParseInt can return NaN so a more efficient way is to use these type of functions
function getNumber(number){
return (parseFloat(number) == NaN)?0.0:parseFloat(number);
}
For date type fields we may use standard Netsuite functions
nlapiStringToDate();
I can't stress enough what a great resource the user group is. I constantly get answers there, many by NetSuite employees, including the creator Evan. Subscribe to the various forums and ask questions. Be sure to mention what you are doing, what you have tried and any thoughts you have on the process you are attempting. I find that when I follow that formula I get answers. Others at my company will just ask how to do something and rarely get any help.
Be aware that many things are not either documented or are not supported in SuiteScript and/or Web Services and the supported list is not consistent between the two.
It is a bit of a nightmare. The help-center section is useful for reference.
https://system.netsuite.com/app/help/helpcenter.nl?topic=help
I second Corey in utilizing the NS user group (recently migrated to https://usergroup.netsuite.com/users/index.php? where I am waiting on approval). Also paying the premium for NS phone support has been helpful in resolving issues. Outside of NS provided support/resources, the linkedin NS user group is pretty decent. I don't find much use out of stackoverflow results for NetSuite problems, probably for the lack of understanding of the system.
NetSuite for Dummies is a good reference for NetSuite in the functional perspective, but offers very little to developers. For Devs, I'd suggest checking out the NS developers guide here https://system.netsuite.com/core/media/media.nl?id=5732122&c=NLCORP&h=5fca4bf5dd825a28ab41&_xt=.pdf&addrcountry=US (old but still relevant). The developers guide contains much of the same information as the help section (albeit the help section is more up to date, but does not have effective searching).