Does anyone know that what are the differences between Vimeo Advance API and their New API?
The new API is a ground up redesign. It's modeled on using RESTful principles, versus the old more RPC style approach. Instead of specifying what you want to do in the URL, you do so with the HTTP verbs common across many modern APIs.
For instance: "GET /me" is how you describe "get the current authenticated user." The old API describes this same action as "GET /api/rest/v2?format=json&method=vimeo.people.getInfo".
There are also other changes to authentication (oAuth 2 versus 1.0a - much simpler to handle) and semantic changes to the responses so you don't have to track IDs and many of the URLs are generated for you to alter.
It's a lot nicer to work with than the old one in my opinion, and it's enabled much faster development in my experience.
Disclosure: I work on building the new API.
Related
Per the original proposal, regarding "Prefer Secure Origins For Powerful New Features"
“Particularly powerful” would mean things like: features that handle personally-identifiable information, features that handle high-value information like credentials or payment instruments, features that provide the origin with control over the UA's trustworthy/native UI, access to sensors on the user's device, or generally any feature that we would provide a user-settable permission or privilege to. Please discuss!
“Particularly powerful” would not mean things like: new rendering and layout features, CSS selectors, innocuous JavaScript APIs like showModalDialog, or the like. I expect that the majority of new work in HTML5 fits in this category. Please discuss!
Yet for some reason service workers have been thrown into the first category. Is there any canonical reason for why this happened?
Jake Archibald from Google in official Service Workers draft spec sandbox,
later cited by Matt Gaunt from HTML5rocks states that
Using service worker you can hijack connections, fabricate, and filter responses. Powerful stuff. While you would use these powers for good, a man-in-the-middle might not. To avoid this, you can only register for service workers on pages served over HTTPS, so we know the service worker the browser receives hasn't been tampered with during its journey through the network.
To me this applies to ServiceWorker:
features that handle personally-identifiable information, features that handle high-value information like credentials or payment instruments
Being basically a proxy between the page and the server a ServiceWorker can easily intercept, read and potentially store each information contained into each request and response travelling from the origin, included personally identifiable information and passwords.
I'm planning to build an application that runs on WEB(AngularJS), Android(Native), IOS(Native).
I have experience with MongoDB, but I found CouchBase which sounds really good for me.
I read documentation and I found out I need to use sync_gatway to sync my mobile databases with main database server and reverse, until now everything is fine.
I also need to use "channels" to share records with multiple users.
The problem comes when I need to implement this for web application.
In their documentation on "Working with web applications" they explain how "bucket shadowing" is working, but they also say:
Bucket shadowing is meant to enable sync for existing Couchbase Server
apps. If you are creating a new app with both mobile and web clients,
we recommend starting with the Sync Gateway REST APIs, and connecting
backend services using the Changes Worker Pattern.
After reading Sync Gateway REST API I found out I'm limited to facebook and persona authentication. So I can't use my own authentication mechanism?
Also, there is nothing specified in REST API about channels?
Is there any example project or more documentation about this? I couldn't find anything :(
If someone has experience with this, please explain how this works.
Thanks
There is also Custom (Indirect) Authentication available on Sync Gateway, which you can use for any type of auth you need.
But you have to hide Sync Gateway's Admin API under your backend layer.
As for the channels: it is responsibility of Sync Function to route different documents to necessary channels based on Document data.
Here is a good video that describes how to build production architecture around Couchbase Lite.
I'm probably late for the party - but as of today I'd recommend taking a look in the PouchDB project for the WEB AngularJS side - they match pretty well and will sync with Couchbase.
Regarding authentication, I just released an article on that topic, find it here. Hope this helps somebody
I basically want to write an app that uses the Drive API. developers.google.com has tutorials on how to do that. But problem is that their example asks me to first create an app engine instance, which I don't want to, as I've heard pretty bad reviews about it. So, I just wanted to know whether there is/are any alternative/s available, and what challenges I would possibly have to face when using the service/s.
You can write a Drive app on any platform that can make an HTTPS request, so pretty much, any platform. When you choose one, if you have any problems, get back to us.
Also, you should probably try out App Engine before making a decision based on "reviews you read".
AppEngine has a few convenience classes around Credential storage and User Id. Aside from that a standard servlet app and a GAE app are pretty much the same.
I've built a simple RESTful API for game developers to do things like authenticate against our user store, post scores, and get leaderboards. It's not perfect, but it's very well documented and is working pretty well for 50% of game developers.
The other 50% seem to be Flash developers who just don't get the idea of a RESTful API. I really don't want to build a wrapper for these developers—I'm not a Flash developer, have no interest in becoming one, and really want to keep everything about our API technology-agnostic.
Can anyone recommend a good tutorial on how to consume a RESTful API for Flash developers?
Given my experience with this problem, I suspect this may have less to do with the fact that the developers don't understand the API and more to do with the limitations of the flash player: it simply doesn't support the full range of HTTP methods (at least, not without a proxy) you've probably used in your RESTful API implementation (such as PUT and DELETE).
Flash only supports GET and POST.
If this is indeed the issue, you'll need to offer an alternative to the missing HTTP verbs. I've worked around this in the past by using POST and adding a 'method=http_method' parameter to the query string.
Another gotcha could be your lack of a crossdomain.xml file.
I was searching for a solution of the following problem, so far without success: I'm planning a RESTful web service, where certain actions (e.g. DELETE) should require a special authentication.
The idea is, that users have a normal username/password login (session based or Basic Auth, doesn't really matter here) using which they can access the service. Some actions require an additional authentication in form of a PIN code or maybe even a one-time password. Including the extra piece of authentication into the login process is not possible (and would miss the point of the whole exercise).
I thought about special headers (something like X-OTP-Authetication) but that would make it impossible to access the service via a standard HTML page (no means to include a custom header into a link).
Another option was HTTP query parameters, but that seems to be discouraged, especially for DELETE.
Any ideas how to tackle this problem?
From REST Web Service Security with jQuery Front-End
If you haven't already, I'd recommend some reading on OAuth 1.0 and 2.0. They are both used by some of the bigger API, such as Facebook, Netflix, Twitter, and more. 2.0 is still in draft, but that hasn't stopped anyone from implementing it and using it as it is more simple for a client to use. It sounds like you want something more complicated and more secure, so you might want to focus on 1.0.
I always found Netflix's Authentication Overview to be a good explanation for clients.