Authorisation
In order to use the API provided by the application, the Client needs a valid authorization token.
Getting an Authorisation Token
- Client provides us with a Client ID and Client Secret and a Username and Password that they want to use in future interactions with us.
- This client information is registered with our system.
- Our system is configured to only accept requests for tokens from registered clients. To request an account please send an email to support at topsapi.support@rockshore.net
- To get a token the client developer sends an HTTPS POST request to:
/oauth/token?grant_type=password&username=Username&password=Passwordsetting the Authorization HTTP header field to the BASE64 encoded value of the "Client ID:Client Secret" string.
For example, if the Client ID is "myClientId" and the Client Secret is "myClientSecret", the header should beAuthorization: Basic bXlDbGllbnRJZDpteUNsaWVudFNlY3JldA==After the call has been made, a 200 HTTP response back will be received, containing a body like the follow:{
"access_token":"fae8c422-d401-11e5-ab30-625662870761",
"token_type":"bearer",
"refresh_token":"0679c886-d402-11e5-ab30-141782870555",
"expires_in":43199,
"scope":"read write"
} - The token (access_token) generated in the previous step should be noted and kept by the development partner.
Using an Authorisation Token
- All the REST calls should be made as normal (GET/POST/PUT/DELETE etc.)
- The header for each request should contain:
Authorization: Bearer fae8c422-d401-11e5-ab30-625662870761Where the token (access_token) generated earlier is used as the value after the Bearer keyword.
-
Deprecated.
Deprecated:
{{baseUrl.value || ' '}}{{role}}{{$last ? '' : ', '}}Body
Accept:no typeReturns
Content-Type:no typeResponse Headers
Status codes
-
Interfaces not documented
MireDot believes that the Java methods below correspond to REST interfaces, but somehow had problems parsing/processing these interfaces and therefore excluded them from the generated documentation. We would very much appreciate it if you would send us the interfaces (not the implementations) and the types used (returntype, parameters). This will allow us to further improve MireDot and better document your interfaces in the future.
Below is a list of potential problems detected by MireDot. They can be severe or not. Some of them wil result in low quality documentation, some are real implementation issues. With each warning, the Java method causing the problem is documented.