[block:callout] { "type": "info", "title": "The API Docs have moved to a new website", "body": "Go to **[api.safedev.org](https://api.safedev.org/)** to find the latest version of the API Docs." } [/block] SAFE Launcher exposes REST APIs for applications to exchange data with the SAFE Network. ## Access Types SAFE Launcher provides two network data access types: ### Unauthorised Access Unencrypted public data can be accessed without any authorisation. For example, websites and blogs, which are made available for public viewing, require no authorisation. ### Authorised Access Applications have to authorise with SAFE Launcher to get Authorised Access. SAFE Launcher will grant an authorisation token once the user authorises the application. Applications will use the obtained authorisation token to invoke the REST API calls. These tokens are session based and thus will be valid only while SAFE Launcher is running. ## SAFE Drive The SAFE Drive directory (`SAFEDrive`) is created by default for every account. Applications cannot access the SAFE Drive directory unless the user grants the `SAFE_DRIVE_ACCESS` permission at the time of authorisation. Users can use their SAFE Drive to store private and public data. For example, they can use it to store documents, images, audio files, videos, websites...etc.... SAFE Drive can also be used by applications for sharing data. For example, a camera app can store images in SAFE Drive and another image editing application can read the images from SAFE Drive. ## Application Directory When an application is authorised for the first time, a root directory for the application is created and mapped to the account. The application can store and retrieve data only from this root directory, it cannot access the root directory of other apps. If the app needs to access `SAFEDrive`, it must send an authorisation request with the `SAFE_DRIVE_ACCESS` permission and the user must grant the permission. [block:api-header] { "type": "basic", "title": "Web Development" } [/block] Since the web pages are supported via a web proxy, the endpoint for accessing the API should be `http://api.safenet` instead of `http://localhost:8100`. The web proxy injects CSP headers to prevent mixing clearnet with safenet. Here are the CSP Headers: ``` Content-Security-Policy: default-src 'self' *.safenet; object-src 'none'; base-uri 'self'; form-action http://api.safenet; frame-ancestors *.safenet; child-src *.safenet X-Frame-Options: SAMEORIGIN ``` This prevents usage of inline JavaScript and CSS which is a restriction at present. [block:api-header] { "type": "basic", "title": "Limitations" } [/block] * The NFS **modify file content** API endpoint has been temporarily deprecated. Currently `SequentialEncryptor` is used via `safe_core` to write chunks as and when available which does not support taking offsets. Once the `self_encryption` crate can support taking offsets while also writing chunks to the network as and when chunks are formed, the modify file API will be re-enabled. At present the workaround for modifying a file will be to delete and create it again as a new file.