Basic concepts
Currently, the following functions can be accessed in the form of web pages:
1. Collaborative documentation
A collaborative document refers to an online document/sheet/slide that can be collaborated by multiple people in real time.
Graphite documents can be created directly for viewing/editing. Local files can also be converted into collaborative documents for viewing/editing through the API interface (see Import Interface).
To preview a collaborative document, set the user's permissions on the document to read-only, refer to the section on Obtaining File Meta Informationpermissions.
The storage format is graphite-specific, not Office files; files are stored on graphite servers;
To convert an online document into an Office file, refer to the Export Interface .
2. File preview
File preview is to convert the files of the access party into a web-supported format for preview and viewing.
This mode cannot be edited, if you need to edit, please refer to the previous section.
Basic process
Access
To access the Graphite SDK, you need to understand the following concepts, and you need to support the front-end and back-end development of the accessing party.
Get appId andsecret
appIdIt is used for the graphite server to identify which service provider it comes from, and theappIdcorresponding data of different cannot be interconnected. The format is similar400bdc777f31d6e63ae8eb5dcb4c0e63.secretUsed to sign the request, the graphite server will verify the legitimacy of the request through the signature. All interfaces that call the graphite server need to carry the signature information, and the signature information is generated bysecretand the specified formatpayload, click to view the specific logic and code examples.
appId and secret Issued by Graphite Systems. Please contact Graphite for the appropriate appId secret and use.
When calling the graphite server interface, you need to carry both the and appId signature information. After receiving the request, the graphite server will first identify the identity of the access party, then verify whether the signature is legitimate, and finally perform subsequent actions such as callback interfaces.
Develop web pages
Provide a container (HTMLElement) to host the Graphite Editor (step A in the diagram).
Generate a user token
In step 4 of the figure, the graphite server needs to request the basic information of the current file from the accessing server after receiving the request, so the accessing party needs to generate a user token for the accessing server to identify the user when processing the graphite server request. This token is only used by the Graphite server for passing.
When accessing the access server, the user token is passed in the form of an HTTP header X-Shimo-Token .
There is no restriction on the format of the user token, and the user ID can even be used directly in the early testing stage. The accessing party needs to develop a way to generate tokens according to its own security policies.
Use the Graphite JSSDK
The purpose of the JSSDK is to generate an editor address that points to the graphite server, which is then loaded into the current page as an iframe. It also encapsulates the iframe page communication method for some basic operations. See Graphite JSSDK for details.
Develop a callback API
In step 4 of the figure, the accessing party needs to provide several interfaces for graphite to call. The core interface is to provide basic information about the file and the permissions of the current user on the file. These interfaces need to be accessible by the graphite server, and will only be accessed by the graphite server. The access party may need to configure a firewall or IP whitelist. The access prefix of the interface is provided when and are obtained appId secret , and the format is similar to abc.com/shimo. The returned result is only available in JSON format. For a list of APIs that need to be implemented, see the access party implementation interface.