<roles_uri>/{roleName}[.<format>]
role resource is the detailed role resource. Through the role resource, you can get and change the configuration of the role. You can also delete this role.
Supported Methods:
Supported output formats: rjson, json, html, xml.
Implement the HTTP request on the following URI, where supermapiserver is the server name, with rjson being the output format.
http://supermapiserver:8090/iserver/manager/security/roles/{roleName}.rjson
Gets the configuration information of the role.
Implement the GET request on role. Return the configuration of the specified role. Made up by the following fields:
| Field | Type | Description |
| description | String | Role description info. |
| name | String | Role name. |
| permissions | RolePermissions | Role permissions include the service access and service management. When the role type is the user, you can change the current role authorization access services or prohibited access services; when the role type is the service manager, you can not only conduct service access authorization, but also can change the service instance list managed by the role. |
| userGroups | String[] | The user group that has this role. |
| users | String[] | The user that has this role. |
The returned rjson format representation after implementing the GET request on the role resource http://localhost:8090/iserver/manager/security/roles/ROLE1.rjson is as follows:
{
"description": "the first role to be created",
"name": "ROLE1",
"permissions": {
"componentManagerPermissions": {
"denied": [],
"permitted": []
},
"instanceAccessPermissions": {
"denied": [],
"permitted": []
},
"publishEnabled": false
},
"userGroups": [],
"users": ["guest1"]
}
Modifies the configuration information of the role.
When sending a request, it needs to contain the following parameters. The role name can not be changes. Other parameters are the optional parameters.
| Name | Type | Description |
| role | Role | Role name. |
| description | String | Role description info. |
| permissions | RolePermissions | Role permissions include the service access and service management. When the role type is the user, you can change the current role authorization access services or prohibited access services; when the role type is the service manager, you can not only conduct service access authorization, but also can change the service instance list managed by the role. |
| users | String[] | The user that has this role. |
| userGroups | String[] | The user group that has this role. |
The resource representation structure is as follows after implementing the PUT request.
| Field | Type | Description |
|
succeed |
boolean | Whether to modify the role successfully. |
Implement PUT request on the role resource (http://localhost:8090/iserver/manager/security/roles/ROLE1.rjson). You can change the configuration information related to this role. Change the role permission. For example, if the user (guest1) forbid to access data-jingjin/rest, data-world/rest and map-china400/rest, the request body is as follows:
{
"name": "ROLE1",
"description": "the first role to be created",
"permissions": {
"componentManagerPermissions": {
"permitted": [],
"denied": []
},
"publishEnabled": false,
"instanceAccessPermissions": {
"permitted": [],
"denied": [
"data-jingjin/rest",
"data-world/rest",
"map-china400/rest"
]
}
},
"users": [
"guest1"
],
"userGroups": []
}
The returned rjson format is as follows:
{
"succeed": true
}
Deletes the role.
The resource representation structure is as follows after implementing the DELETE request.
| Field | Type | Description |
|
succeed |
boolean | Whether to delete the role successfully. |
Implement the DELETE request on the role resource http://localhost:8090/iserver/manager/security/roles/ROLE1.rjson. You can delete the role specified by role. The returned rjson format response result is as follows:
{
"succeed": true
}
Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content. The meta-information includes the media-type, content-encoding, transfer-encoding, content-length, etc.
HEAD request can be used to check if the role resource exists, or if the role resource can be accessed by clients. It can also determine if the role resource supports an output format <format> if performed on a URI with .<format> included.