I have to develop a small daemon, using flask and Dropbox API, that downloads files from my Dropbox account to my local database.
It is my first contact with the Dropbox API.
So I am confused in the choice of the class that I should use:
Dropbox.dropbox class or Dropbox.client class?!
What is the difference between the two classes?!
and what the best use for each class?
Thank you
You should use the dropbox.Dropbox class. That uses the current version of the Dropbox API, which is API v2.
The client class is offered for backwards compatibility, and uses the deprecated API v1.
Related
since Google announced that Google+ Sign-in will be fully deprecated in near future, I just want to confirm that I understand we are not using any of its deprecated features.
Currently in our code I can see that we are only using following two classes:
com.google.api.services.oauth2.Oauth2
com.google.api.services.oauth2.model.Userinfoplus
Under 1, part of the code we are worried about is
public class Me
which, as far as I understand, addresses plus.me (https://developers.google.com/identity/sign-in/web/quick-migration-guide), which is being deprecated.
Under 2, is this class also being deprecated? It seems like the part (or all) of the Google+ profile is contained in there.
Both classes mentioned above are part of the following library version:
com.google.apis:google-api-services-oauth2:v2-rev77-1.19.0
The version of api-client is:
com.google.api-client:google-api-client:1.19.0
Many thnx
The Me class does not appear to be related to the plus.get endpoint. The Path specified in the Me.Get class is
private static final String REST_PATH = "userinfo/v2/me";
which specifies the userinfo endpoint, rather than the plus.get endpoint.
Similarly, although the Userinfoplus sure sounds like it is related to the plus endpoint, the fields in it appear to match the userinfo v2 endpoint. They certainly don't do anything to access the plus.me endpoint directly, anyway.
I have created a console application with azure media service.
in the app i am using the plugin
windowsazure.mediaservices
the way i am doing is
static IAsset CreateAssetAndUploadSingleFile(string filePath, string assetName, AssetCreationOptions options)
{
IAsset asset = _context.Assets.Create(assetName, options);
var assetFile = asset.AssetFiles.Create(Path.GetFileName(filePath));
assetFile.Upload(filePath);
return asset;
}
so i just want to know whether this plugin will work on xamarin(i am not a xamarin devoloper) as its a portable project.
if its not do we have any alternative plugin?
my basic purpose is upload and encode.
That package is for our current .NET SDK
https://www.nuget.org/packages/windowsazure.mediaservices
It does not support .NET Core. See the dependencies.
It's not compiled for Xamarin though, so I don't believe that it works in Xamarin, but i'm not a Xamarin expert at all.
What is your scenario exactly? Why would you want to call the Media Services account directly from Xamarin anyways? You would only need to do that if you are creating a management application for the account Administrator. Otherwise, dont put Media Services directly into any client code! You should hide it in your middle-tier, and only pass Streaming URLs or SAS locators to the client application to upload content to.
For the upload from phone scenario, middle tier should create an Asset, get a writable SAS Locator for the Asset, hand that to the client side. Client can then use Azure Storage APIs to upload the content to that SAS URL directly (it ends up in an Azure storage container then.)
I believe that Xamarin has client side support for the Azure Storage APIs available.
As john answered, you don't do this stuff on a client, you will need to use SaS tokens and what not. I could explain everything here, but there are some nice guides and examples online.
Build 2018 video explaining how it works (including Azure Functions): https://www.youtube.com/watch?v=dEZkQNNpSIQ&feature=youtu.be&rel=0
The github example of this video: https://github.com/Azure-Samples/xamarin-azure-businessreview
To understand it better, I recommend this guide, it is old but it does cover the entire process, just make sure to combine new documentation with this old one.
Old docu: https://learn.microsoft.com/en-us/previous-versions/msp-n-p/dn735912(v%3dpandp.10)
Official current documentation: https://learn.microsoft.com/en-us/azure/media-services/previous/media-services-dotnet-upload-files#upload-multiple-files-with-media-services-net-sdk
Probably useful for new readers.
I want to get the image list and download those images from a Dropbox's public-shared-link, which I get it from my client.
I'm using Dropbox SDK for ruby and only find the methods to manage files via my Dropbox account, such as put_file, get_file, get_file_and_metadata, get_chunked_uploader, upload and so on.
Is there any way to do that?
Dropbox API v1 has an endpoint that allows you to retrieve metadata about shared links:
https://www.dropbox.com/developers-v1/core/docs#metadata-link
Dropbox API v2 has a similar pair of endpoints that allows you to retrieve metadata and file content, respectively, from shared links:
https://www.dropbox.com/developers/documentation/http/documentation#sharing-get_shared_link_metadata
https://www.dropbox.com/developers/documentation/http/documentation#sharing-get_shared_link_file
Unfortunately, none of these are currently implemented in the Ruby SDK. You can call them directly though, or modify the Ruby SDK to do so.
I am writing a Padrino app which will expose a few services via REST apis. I need to version the apis. I found this answer which explains how to version an api such that the version is embedded in the uri. I would rather put my version info in the Accept header or some other HTTP header (let's not go into the whole embed-in-uri vs put-in-header debate for now). Is there an idiomatic way of implementing this in a Padrino controller? I would like to avoid littering version checks in all my routes. Is there any way I can put the check in a central place (DRY) or - better still - let Padrino take care of this for me with some magical directives?
Try to implement (ofc, w/o 'v1' in url) this.
Also found that. It should work since Padrino is the little bro of Sinatra.
Can't test for the moment. Please keep me aware !
What is the best approach to version WebAPIs?
I am building an API from scratch and I would like to ensure that it will version gracefully in the future. I am envisioning something like mysite.com/api/v2/...
One approach I see is to create a separate project (web app) for each version of API. But perhaps there are better ways to do it?
Thank you for your ideas.
Including version number in the URL is the standard approach as I explained in this post (I do not repeat the content): Implementing versioning a RESTful API with WCF or ASP.Net Web Api
You do not need to create a completely new project although you can. The problem that you will be facing with a single project is that there will be collision of names:
/api/v1.0/Car/123
and
/api/v2.0/Car/123
both will point to CarController while you can have only one of those. The solution would be to implement your own IHttpControllerSelector and register with the DependencyResolver. This implementation will look at the version number and perhaps find the type based on the namespace.
UPDATE
I do not intend to start a REST controversy here. But as #DarrelMiller points out, here is an older discussion on the same subject discouraging my suggested approach:
How to version REST URIs
I personally think URL versioning is the way to go.
You will need to create your own implementation of IHttpControllerSelector. The best way is to base this implementation on Microsoft's IHttpControllerSelector. Then you can decide in your IHttpControllerSelectorif you want to version by URL or by content-type.
The most basic implementation directly implements IHttpControllerSelector and just implements the SelectController method but performance reasons it is better to implement some caching around it.
For finding the Controller you simple the IHttpControllerTypeResolver instance you can get using HttpConfiguration.Services.
I've used something like this: http://damsteen.nl/blog/implementing-versioning-in-asp.net-web-api. Also put some code on Github: https://github.com/Sebazzz/SDammann.WebApi.Versioning.