12/25/2023 0 Comments Sugarsync user guide![]() A user can recover files from the Deleted Files folder. Alternatively, a file can be moved to the Deleted Files folder. Files deleted using the SugarSync service are permanently removed from the system and cannot be recovered. Remove Files With Careīe certain that the user truly wants to delete a file. Your app can retrieve the link to the user’s Deleted Files folder from the element in the user resource representation.įor more information about deleting a folder, see Deleting a Folder. A folder (and all its contents) in the Deleted Files folder can be recovered. If your app deletes a folder without first deleting its contents, the contents may be rendered inaccessible.Īn alternative to permanently deleting a folder is moving it to the Deleted Files folder. That’s because removing a folder through the SugarSync service does not remove the objects contained within the folder. If your application needs to delete a folder, it’s important to first remove the contents of the folder. ![]() Remove Folder Contents Before You Delete a Folder ![]() The SugarSync service requires XML input to be encoded using UTF-8 encoding, and generates XML output using UTF-8 encoding. When your application specifies XML input as part of a request - for example, when it makes a request to create an authorization token or when it creates a file - the XML must specify UTF-8 encoding. Your requests should specify a User-Agent header field value that is specific to your application. Note that all the examples in the User’s Guide that show request headers specify a User-Agent header field value of Jakarta Commons-HttpClient/3.1. The header should identify the application, including the specific version of the application. Specify Application-Specific User Agent StringsĮach application that you develop should provide a User-Agent header in all requests to the SugarSync API. For more information about retrieving these URLs, see Getting Information About a User. Your app can store that URL and reuse it in the future without having to retrieve it every time from that user’s user resource. For example, the URL in the element that your app retrieves when it requests information about a SugarSync user account is a persistent URL that represents the user’s Magic Briefcase. The URLs for a specific user account that your app retrieves from the SugarSync service are persistent for that user account. In this way, not all users of your applications will be impacted if a single set of keys is compromised.įor more information about access keys, see Authorization to Make API Requests. This means that if you develop more than one app, you’ll need to generate a new set of keys for each app you develop. In addition, use a different developer key-private access key pair for each application. You don’t want to give anyone else this unique access ability. Your developer keys provide an authorized connection to the SugarSync platform exclusively from your app. ![]() When you sign up as a developer with SugarSync, we’ll issue you two access keys: one is your unique developer key and one is your private access key. Here you’ll find a number of recommended practices when using the SugarSync Platform API in your applications.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |