Overview of the ring server-side rest platform about rest
REST (representational state Transfer) is a lightweight Web service architecture style that can be translated into "representational transitions", which are significantly simpler to implement and manipulate than soap and XML-RPC. Can be implemented entirely through the HTTP protocol, and cache caches can be used to improve responsiveness, with better performance, efficiency, and ease of use than the SOAP protocol.
The rest architecture follows the CRUD principle, and the crud principle requires only four behaviors for resources: Create, read, Updates (update) and delete (delete) can be processed and manipulated. These four operations are atomic operations, and the operation of resources, including acquiring, creating, modifying, and deleting resources, corresponds exactly to the get, POST, put, and Delete methods provided by the HTTP protocol. Thus, rest restricts HTTP operations to a URL resource within four of Get, POST, put, and delete. This approach to design and development of Web-based applications can reduce the complexity of development and improve the scalability of the system.
More REST API background information can be found in this RESTful API design guide
Rest Platform System
The platform provides a multi-tenant user system, which is described in the form of a collection of "Collection", where Collection includes database, Enterprise (orgs), Applications (apps), IM Users (users), groups (chatgroups) , Messages (Chatmessages), Files (chatfiles), and so on, the containment relationship is
DB = {org1, org2, ...} org = {App1, app2, ...} app = {users, messages, Chatfiles, Chatmessages, Chatgroups, ...} users = {user1, User2, ...} Messages = {message1, Message2, ...} chatfiles = {chatfile1, Chatfile2, ...} chatmessages = {chatmessage1, chatmessage2, ...} CH Atgroups = {group1, group2, ...} multi-tenancy refers to the software architecture supporting an instance service multiple users (customer), each user is called a tenant (Tenant), the software gives the tenant the ability to partially customize the system, such as user interface colors or business rules, but they cannot customize the code to modify the software.
In fact, in the cloud computing world, The meaning of multi-tenancy has been extended. For example, a software as a service (SaaS) provider that uses an application system running on a DB instance to provide Web Access services to multiple users. In such a scenario, the data between the tenants is isolated, and the data for each user is guaranteed to be invisible to the other tenants.
In the ring-letter service system, the user data between different org is isolated from each other, and the user data between different apps under the same org is isolated from each other.
REST Server
The server-side interface of the ring is provided through the rest service, and the rest API is based on the simplest HTTP protocol, providing good support in each programming language.
REST Client
The rest client is the terminal that calls the rest API and can be invoked in many ways: Linux curl, browser, programming language HTTP request access implementation, and so on.
Invoking the rest API is essentially sending an HTTP request, except that it may be common for HTTP GET and HTTP POST_ requests, but _http put and HTTP DELETE are often used in rest, and in rest, these four operations are called dynamic Words, can be (not particularly accurate) of the imagination into additions and deletions to change.
The object that the verb operates, in rest, is called the resource, which is _url, which is also the content of the standard HTTP protocol. In fact, when we open a Web site in the browser, for example, open www.easemob.com, the browser actually sent to the Web server, is an HTTP GET request.
It is important to note that the rest API of the ring is JSON-based, so when constructing the _HTTP_ request, you need to specify it in the _http header_:
Header_name |
Header_value |
Description |
Accept |
Application/json |
The type of data returned to the client by the server side |
Content-type |
Application/json |
The data type that the client sends to the server side |
Java
In Java, the rest client is implemented in a variety of ways, such as JBoss Resteasy, Sun Jersey, Dropwizard, Apache HTTPClient. We recommend using Jersey to invoke the rest service of the ring letter, Jersy 2.x implements the JAX-RS 2.0 specification and provides asynchronous support, but Jersey 2.x requires JDK 1.7 support, so if your server-side program has no way to use JDK 1.7, then you need to use Jersey 1. version of X. There are also many people who use Apache Http Client directly, we do not recommend the use of this library directly, mainly because the library is relatively low-level, need to handle a lot of things, the API is relatively cumbersome.
Python
For Python programs, we recommend using the Request class library to invoke the rest service of the ring-letter.
The basic architecture of the ring-letter server
When the user registers in the background of the Ring Trust developer, it is necessary to fill out an "Enterprise ID", because the ring is a multi-tenant-enabled cloud service platform, and the ring letter is to support the "enterprise" (or understand the team)-"App" level two structure. That is, in the ring-letter platform, The data between each enterprise ID is strictly isolated from each other, and the data between each app within each enterprise ID is strictly isolated from each other.
You can imagine a model like this: There are three departments in a company, each department is responsible for an app, then the company can register a ring letter account, and then in the name of the account to create three (the ring in the) app, each of the app in the ring letter to a department app.
In this way, the initial registration of the account, is the enterprise in the Ring Letter Enterprise Administrator account, the Enterprise administrator can create a new app, and assign the app Administrator account, on the access rights, the enterprise administrator has the highest permissions, can see their own enterprise ID all the data in the app, The app manager can only see the data in his app and can't see the data in other apps. At the same time, as mentioned above, the same enterprise ID under the app, the data are also isolated from each other, so you can completely in two apps to create the same user name of the user.
In addition, if only a personal developer to develop an app, then the enterprise ID can be filled out, just do not and the ring letter existing Enterprise ID duplicate.
Finally, because the ring provides the rest service, and as stated above, the rest essence is to manipulate the resource (URL) through the get/post/put/delete, so it can actually be seen in the rest API of the ring-letter.
Assuming an enterprise ID of Easemob-demo, and then this enterprise has an app name called Chatdemoui, then the rest API of the ring is like this
Get all users under this app
Path:/easemob-demo/chatdemoui/usershttp method:getrequest Headers: { authorization:bearer ${token}}
Get the details of the user Stliu under this app
Path:/easemob-demo/chatdemoui/users/stliuhttp method:getrequest Headers: { authorization:bearer ${token}}
Create a new user under this app
Path:/easemob-demo/chatdemoui/usershttp method:postrequest Headers: { Content-type:application/json, Authorization:bearer ${token}}request Body: {"username": "stliu1", "Password": "123456"}//Note: The post data needs to be in JSON format, and set Content-type to Application/json
Delete a user
Path:/easemob-demo/chatdemoui/users/stliuhttp method:deleterequest Headers: { authorization:bearer ${token}}
From the above URL rules, you can also see the "Enterprise" – "App" – the "user" layer of progressive relationships.
noun explanation
noun |
explain |
Org_name |
The company's unique identity, the enterprise ID that the developer fills in when registering an account with the ring developer admin |
App_name |
The "app" is uniquely identified under the same "enterprise", and the developer fills in the "app name" when creating an app in the background of the ring developer management. |
Org_admin |
The "user name" that developers fill out when they register with the ring developer. Enterprise Admins have access to all resources under the enterprise account |
App_admin |
Application administrator, a special IM user with admin privileges, with permission to operate on all resources under the app |
Appkey |
Unique identifier of an app, the rule is ${org_name}#${app_name} |
Safety
The rest service of the ring is a security protocol based on HTTPS, which guarantees from the protocol level that it will not be stolen by others when it is called.
The backend service API for the ring is secure, and is based on the OAuth 2.0 Standard and RBAC (role-based access control) permissions model.
Before calling the backend service of the ring, you need to login to get token, and depending on the role of the requesting initiator, the way to get tokens is different.
For OAuth 2.0, you can refer to this article to understand OAuth 2.0
Sample code
The Ring letter provides sample code for how to invoke the rest service, which can be found here.
Introduction to the Ring letter _