According to the documentation a GET request to /v2/feeds "will return a snapshot of each Xively Feed that is viewable by the authenticated account." When I invoke this service the results include lots of public feeds, but not my own development-mode feeds even though my API Key has access to them. Is that the intended behaviour or am I missing something?
The /v2/products resource provides what I need: I can enumerate my products and then enumerate the devices in each product, but it's not supported by the Xively Java library as far as I can see.
Products and devices are not supported in some libraries. If you want to enumerate all of your feeds (including development mode) the best thing to do is use the feed search API, the documentation for which is here.
What you probably want to do is return all of the feeds attached to your user account. Call this URL api.xively.com/v2/feeds?user=USERNAME.
Related
Woocommerce provides an API here which in order to use it, you have to provide a consumer key and consumer secret with a relevant authorization schema. What I fail to grasp is that, shouldn't be there an API for unauthorized / guest users ? I mean, I just want to create a display page (frontend) of available products, but without the need of generating CK/CS. Also looking in a similar question here
it seems that you cannot avoid using the keys. But a second question comes up. The frontend is not supposed to use the keys, because then the e-shop becomes exposed to the client. So, even by generating these keys in order to access woocommerce api, how am I supposed to correctly use them ? Please help me understand the flow.
TLDR;
Do NOT use CK/CS in front end. It's only for use in a secure backend. The keys can be used to read/write anything from products to, orders to all customer related information.
Based on you questions, I suspect APIs might not be the best way to do what you're intending to do. If you do need APIs, chances are, you have two backend servers communicating with each other. APIs are usually meant for use by other applications. For example, a lot of Point of Sale systems utilize this WooCommerce API. You might want to look into extending the WooCommerce plugin itself and creating end points to get the information or perform actions you need.
If you are not familiar with secure Authenticated APIs, I would highly suggest you familiarize yourself with them as failure to secure the website can result in huge financial losses to sensitive personal information leakage of the site users since WooCommerce APIs, at the time of this writing, only allows you to set read or write permissions with full access to everything.
With that in mind I will attempt to answer all of your questions one by one and give an idea of how you should use it.
To Answer your questions
What I fail to grasp is that, shouldn't be there an API for
unauthorized / guest users ? I mean, I just want to create a display
page (frontend) of available products, but without the need of
generating CK/CS
I'm guessing your misconception is that you need to use separate keys for each user. API keys are not meant to give access for front-end users. The API keys generated by the WooCommerece plugin gives full read/write access to any user to view/modify any information including that of other customers. Its meant for admins. If you check the official WooCommerce API reference for retrieving a customer you'll notice that you get to provide an id here. And if you check the response it shows everything from addresses to contact information.
The frontend is not supposed to use the keys, because then the e-shop
becomes exposed to the client. So, even by generating these keys in
order to access woocommerce api, how am I supposed to correctly use
them ?
Its quite simple actually. You just need to get between the communication between the front-end users and the WooCommerce API. If the users needs to be provided information from the WooCommerce end point, you need to get it for them using the CK/CS.
This way, you confirm what information is allowed to view/modify by whom, and the user does not need to be authenticated.
WooCommerce Endpoints <---> Your secure backend service/middleware/controller <---> front-end user
One thing to note though, is that you need to be careful about the parameters a front-end user is able to change in the request to your server end-point that is consuming the WooCommerce API key. A customer should not be able to change the id that is requesting their info for example. Id should be retrieved from the backend from the secure authentication information coming from the front-end.
We are using autosuggest feature on iOS and Android, and we want to show full address for places found during request.
It is not very good solution to make additional request for every found place to get an address.
When using REST API I can add property show=details to get address in response. For example https://autosuggest.search.hereapi.com/v1/autosuggest?at=51.5074,0.1278&limit=5&q=Wind&show=details
But I haven't found such possibility on native SDKs.
Is it possible to add address to autosuggest query results with native SDKs? Or should I use other API?
In the iOS and Android SDKs the place details must be fetched in an additional request.
com.here.android.mpa.search.AutoSuggestPlace
Represents an AutoSuggestPlace which contains information about a suggested Place.
Note: detailed Place information is retrieved by way of the PlaceRequest returned from a call to the AutoSuggestPlace.getPlaceDetailsRequest() method.
I'm still struggling a bit with how to use and organize Paw files (*.paw documents), particularly as an API consumer. Is it smarter to:
Organize by project (i.e. project A consumes these particular API calls, so create a my-project.paw document for that project/client); or
Organize by API service (i.e. a MailChimp.paw document defining the various MailChimp endpoints, then add new environments for each project that consumes the MailChimp API)?
(As a side note, it would be great if there were a public repository for sharing .paw files for popular APIs!)
There's no rule, you may organize stuff as it fits to your use case, but I'd recommend organizing files around APIs, so it's all ordered around the given API, following its standard, groupping requests depending on the resources served by the API. One tree example would be:
My-Blog-API.paw
Users (a group)
Get one user (GET /users/:id)
Create user (POST /users)
Articles (a group)
Get list of articles (GET /articles)
Get one article (GET /articles/:id)
Create article (POST /articles)
This way your document closely follows the semantic of the API. Also, it allows a good organization of your Environments, to store for example the Base URL of your API, or the user credentials/access token(s).
Though, maybe I'd keep a "Related" folder for calls to 3rd party services needed for the API calls. For example, you may want to have a call to the Twitter API to get an access token, you'd pass then to your API for the "login with Twitter" feature.
Related (a group)
Twitter (a group)
Login with Twitter (GET https://api.twitter.com/login – whatever I don't know the exact URL)
(Also, thanks for the idea of creating a public repo, some have shared Paw collections on their website, but it would be nice!)
I'm using this link https://www.google.com/reader/api/0/stream/contents/feed/FEEDHERE?output=json&n=20
to fetch feeds using Google's algorithm. As you can see I'm not adding any other parameters, just fetching the returned data in JSON format. My app will be heavily used hopefully and if I send a lot of requests to this link, will Google block my access or something?
Is there anything I can include, like userip, url for my app (so if they have problem to just contact me) or something else?
The most basic answer to your question is that Google will change its Terms of Service whenever it likes, and you've got no say in the matter. So if it's allowed today, it might not be allowed tomorrow, at Google's whim.
On this issue, though, you seem fairly safe. From the Terms of Service (these is the general document, since Reader doesn't seem to have a specific one):
Don’t misuse our Services. For example, don’t interfere with our Services or try to access them using a method other than the interface and the instructions that we provide.
Google provides RSS and Atom. They provide these feeds, so I assume they expect that they'll be used. They don't say that it's a misuse to point someone else at those feeds, so it looks OK for now, but they could add such a clause at any time.
All online services are subject to the terms and conditions of the providers of those services. So, as others have said, they may be ok with your use today, but they can change their mind any time down the line. I doubt including a URL or email or contact info will help anything, because when these services change, they don't notify every user of the service, they just announce the change publicly, and usually they give several month's notice in order to give users a chance to adapt their applications, but this is not standardized or enforced so there is no guarantee. One example would be the fairly recent discontinuance of the Google Finance API (for which no replacement has been announced).
The safest approach would be to design your app such that this feature that uses google's functionality is decoupled as much as possible from the rest of your app, so that, when or if the availability of the service changes (ie it's no longer available at all) you can adapt your app to use some other source for the feeds with minimal impact to the rest of the app. Design for change and plan for the worst.
I want to create an in-house RSS feed (I work for 3 Mobile, Australia) for consumption on an INQ1 mobile phone, or any other RSS reader for that matter. However, testing it out on the phone's built-in RSS reader, I realize that without the ability to password protect the feed, or otherwise restrict access to it, I stand little chance of being able to develop this idea further.
One thing I thought of was to periodically change the Uri for the feed, so managers who had left the company couldn't continue to subscribe and see sensitive information, but the idea of making users do that would make it a harder sell, and furthermore is terribly inelegant.
Does anybody know how to make it so that prior to downloading a feed, a reader would have to authenticate the user? Is it part of the metadata within the feed, or something you would set in the reader software?
Update: I should have explained that I already have placed folder-level permissions on the parent folder, which brings up the normal authentication dialog when the feed is viewed in a browser, but which just results in a failed update with no explanation or warning in the phone's RSS reader, and is indistiguishable from the file being missing, when I next try and refresh the feed.
If the reader in the phone doesn't support HTTP Basic or Digest, your best bet is to create a unique url to the feed for each consumer. Have the customer login and generate a link with some token in it that is unique for that user. If the user ever leaves, you can then deny that token, shutting down access.
If you go this route, you probably want to investigate including the Feed Access Control bits in your feed. It's not perfect, but it is respected by the bigger aggregators, so if one of your clients decides to subscribe to the feed with Reader or Bloglines, things shouldn't show up in search results.
I believe you would set the permissions on the feed itself, forcing authentication, much like the Twitter feeds. The problem with this is that many readers (including Google Reader) don't yet support authenticated feeds.
The idea is to have authentication over a secure channel. These posts explain it pretty well:
RSS Security
Private RSS Feeds
Authentication by the webserver is probably the best solution, however to get round the issues of reader not supporting it (Google has been mentioned and I have issues with Safari) you could implement a simple value-key to append to the URL.
I.E.
http://www.mydomain/rss.php?key=value
Your system could then "authenticate" the key-value and output the RSS, invalid k-v could get a standard "invalid authenticate" message as single item RSS or return a 40x error.
It not very secure as you could see the k-v in the URL but it's a a trade off. An un-authenticated HTTPS would be slightly more secure.
Assuming your RSS feed is over HTTP then basic HTTP authentication would probably do the trick. This would either be done at the web server level (in IIS for example) or via whatever framework you're using to produce the feed (in ASP.NET for example).
The authentication scheme (basic username/password, NTLM, Kerberos etc) is up to you. If you're using WCF to produce the feed then these decisions are things you can make later and apply via config if needed.
Are you simply looking to authenticate consumers of the feed, or also encrypt it to prevent the information from being read by a "man in the middle". If you require encryption then SSL is probably the easiest to implement.
You should avoid simply "hiding" the RSS feed by changing it's name.
update:
Your question (with it's update) sounds like you're actually having issues with the RSS client on the device. You need to determine whether the phones RSS client understands how to deal with basic/digest authentication etc.
Assuming it doesn't, is there anything in the HTTP request that could allow you to associate a device with a user? Is there an HTTP Header that gives you a unique device ID? If so, you might be able to then perform a lookup against this data to perform your own weak-authentication, but you should remember that this sort of authentication could be easily spoofed.
Does the device have a client certificate that could be used for mutual SSL? If so, then that would be ideal.