I try to research realTime api with yammer document.But when I browse "https://developer.yammer.com/realtime",it redirect to "https://developer.yammer.com/realtime-deprecated". Does it mean yammer will not support realTime api in the future?
Starting August 2014 we are removing the Realtime API from the documentation. While the Realtime API will continue to be supported and work, it will no longer be available on http://developer.yammer.com/.
We decided to remove it from our documentation because it no longer fits into our longer-term strategy and, while it will still be supported for the foreseeable future, we did not want new developers using it. Also, it’s been available for about 4 years and usage is relatively low.
Related
Apologies in advance for the seemingly naive question, I'm a hobbyist developer learning the ropes. I noticed the opentok REST API documentation deal mainly with command line stuff, whereas the SDKs (web/node SDKs for example) come packaged with class instances, methods, etc. So is one a reference for the other? How/when does one use the REST API instead of the SDKs?
Vonage Developer Advocate here.
Our server SDKs provide a language specific wrapper for our REST API. Both are focused on session & token generation and archiving. This logic is usually processed on the server side.
The client SDKs are different in that they provide capabilities for the front-end.
Since CodenameOne doesn't support "the cloud storage API" any more and the parse.com is going to retire soon as well. Does CodenameOne has any plan to release a new Cloud Storage API or provide suggestions/guidelines to help developers to deal with the parse4cn1 library code, cloud code, database structure and data in parse.com?
That is something you will have to figure out yourself as parse4cn1 was initially contributed by a community member and wasn't developed by Codenameone team.
You can use a simple webservices created in php, python or java, hosted along your content with any ISP.
You may also have a look at amazon aws which is promising, they provide a cloud solution but their SDKs is not yet integrated to Codenameone.
I made the parse4cn1 lib and I'm also wondering what's smartest to do. With the announcement of Parse.com's imminent shutdown, there's been a lot of discussion around alternatives. My feeling is that "the dust is yet to settle" as per what options are best and reliable for the longer term (it would be a pity to migrate to another service only for it to be shut down soon). So I personally plan to wait till sometime in Q2 to do a proper evaluation of the alternatives. Hopefully, there'll be more clarity then.
The option to host one's own Parse server (e.g. on AWS or Heroku) is getting interesting. They recently announced support for push notifications on iOS and Android. If (when?) they open source the Parse.com dashboard code, I think that option would be much more interesting.
At some point in the coming months, I plan to make a parse4cn1 release that exposes an option to set the server path. With that, anyone migrating to the Parse server option should, in principle, be able to continue to use the cn1lib. Of course, for features that are supported by the open source Parse server.
PS: Here are pointers to some of such discussions on Parse alternatives:
https://github.com/relatedcode/ParseAlternatives
http://www.slant.co/topics/5219/compare/~firebase_vs_kumulos_vs_kinvey
As it is stated on their website Google has stopped maintaining the Image search API and it is now deprecated. This is from 2011, as of their policy the API is working for 3 more years before they shut it down. It is now way more than 3 years and the API is working. Does anyone have any information if the API will continue to work and are they shutting it down anytime soon?
Also does this API have any limit to the request per day or anything like that. As i have read the only restriction is the 64 max results per request.
The Google Image Search API has been officially deprecated as of May 26, 2011. It will continue to work as per our deprecation policy, but the number of requests you may make per day may be limited. We encourage you to use the Custom Search API, which now supports image search.
https://developers.google.com/image-search/v1/devguide
I currently developing a multi tenant saas application using asp web api. The api will be published and consumed by 3rd party application. My question is regarding versioning. I'm struggling to find a way to build the api so that when i updated the api, it wont make 3rd party app that uses the api to stop working. I've seen many api append the version no into the url. But that means that i have to keep old version api until all 3rd party app has been upgraded and use the latest api. I also have to update the old api to adapt to database change. That seems like a lot of work. How do big companies solve this problem?
There is no easy way around this; you will have to do the work to support old versions as long as your customers are using them.
Adopting a RESTful approach in the first place, and avoiding 'fat controllers' may help reduce the pain but beyond that every old API call will need to call into your new service layer and will need to return the results in the format your clients expect.
I'm struggling to find a way to build the api so that when i updated the api, it wont make 3rd party app that uses the api to stop working. I've seen many api append the version no into the url. But that means that i have to keep old version api until all 3rd party app has been upgraded and use the latest api.
No one, absolutely no one has researched, built, versioned and maintained APIs more than NetFlix - not externally but internally. They used explicit versioning (e.g. URL) in their APIs and maintained multiple versions of the same API and got their clients move along by providing incentives (new features). This is also something that can be built into your SLA, e.g. you guarantee support of particular version only for 12 months.
This is a very controversial topic and you will hear people suggesting implicit versioning (e.g. by media type etc). Feel free to listen to those but pragmatism favours explicit and purism favours implicit.
I have read about new Google Apps Marketplace and have seen the overview video here.
I'm worried about migration from OAuth1 to OAuth2 and having impact to some developed applications with APIs in my domaine
in the video exactely in 24', comparaison of what libraries/APIs are used in the OAuth1 vs OAuth2, and in 27' talking about turning off the OAuth1.
these Libraries/API will be deprecated ?
Any idea about turning off the OAuth1 and when ?
You need not worry about the impact of OAuth1 to OAuth2. This transition can be completed in a max of 15 days if you have done many integrations with Google. If you are worried just about the SSO with OAuth2 this can be completed in a day as Google has already provided proper documentation regarding the work flow.
Google has even provided migration APIs to upgrade your customers domains from v1 to v2 of Google Apps Marketplace(GAM). If you have a huge user base to be migrated then you need to plan accordingly such that migrated and non-migrated users would be able to use your app for some days till the migration is completed successfully.
Google will announce if it intends to discontinue or make backwards incompatible changes to this API or Service. Google will use commercially reasonable efforts to continue to operate those Google Documents List API versions and features identified at http://developers.google.com/google-apps/documents-list/documents-list-api-list without these changes until April 20, 2015, unless (as Google determines in its reasonable good faith judgment):
So on a safe side it is better to migrate all of your APIs to the latest libraries to avoid any failures at a later point of time. Anyway the older versions are not supported for any issue fixes/ support from Google side. So it is always better to migrate your APIs
Older version of GAM(v1) will also be deprecated at some time but Google hasn't provided any timeline for this. Probably it may take a year(not sure)
Google strongly encourages you to migrate your marketplace application to OAuth2 as soon as possible. Google has already announced deprecation of OAuth1. All top apps on marketplace have migrated their customers to OAuth2 with no issues. We plan to stop allowing installs of OAuth1 applications in near future from the marketplace (specific timelines to be communicated separately).