Introduction to REST API
Tribefire offers two different REST v2 APIs, which you can try out directly from your browser.
On this page
General
API Endpoint | Description |
---|---|
/rest/v2 | Allows you to perform create, read, update, delete (CRUD) operations on entities and properties inside accesses. There are different URL endpoints for entities and accesses. |
/api/v1 | Allows you to evaluate service requests. |
It is advisable to use the following headers for all REST calls:
Header | Value |
---|---|
Accept | application/json |
Content-Type | application/json |
Authentication
Send a POST call to /api/v1/authenticate
for authentication. Make sure to provide your credentials in the body of the request:
Item | Description |
---|---|
Method and Link | POST host:port/tribefire-services/api/v1/authenticate |
Body | { "user": "cortex", "password": "cortex" } |
Headers | Content-Type: application/json |
You have to include the session ID in every REST call. You can include it in the following:
- URL parameter:
sessionId=yourSessionId
- header parameter:
gm-session-id
You cannot include the session ID in the body of the request!
If you are not logged in (there is no valid session) and you paste a GET
call in your browser, you will be redirected to a login screen. After logging in, you will see the result
of your GET
call.
The redirect does not happen for the
/api/v1/authenticate
call.
CRUD with /rest/v2
The /rest/v2
endpoint allows you to perform create, read, update, delete (CRUD) operations on entity instances and properties inside accesses. This endpoint complies as closely as possible with the general REST specifications.
For more information on REST specification, see the following IETF document..
As we comply with the general REST specifications, note the major differences between POST
and PUT
:
POST | PUT |
---|---|
Works on collections | Works on single entities or properties |
Allow creation with autogenerated ID | Create or update for a provided ID If you don't provide an ID, this call fails. |
Entity must exist if ID is specified | Entity doesn't need to exist, it is created with the provided ID if doesn't exist |
Updates/creates entities for every call | Idempotent (multiple calls with same parameter STRICTLY equivalent to a single call) |
URL Endpoints
Within this API, here are the available URL endpoints:
URL | Description |
---|---|
/rest/v2/entities/ {accessId}/ {typeSignature}/ {id}/ {partition} | Executes a CRUD (i.e. Create, Read, Update or Delete) operation on the given entity or entities in the given access. The id and partition parameters are optional. The endpoint provides search capabilities. |
/rest/v2/properties/ {accessId}/ {typeSignature}/ {id}/ {partition}/ {property} | Executes a CRUD operation on the given property, allows for addition and removal in collection properties. The id and partition parameters are optional. |
We also support SimpleName
instead of typeSignature
resolution for entities. That means that you can omit the package declaration: my.model.package.MyEntity
if there is only one entity with this simple name (the last part of the signature) in the model. If there is more than one entity, a 400 Bad request
is thrown.
Here is an overview of all the operations this API offers:
URL | GET | POST | PUT | DELETE | PATCH |
---|---|---|---|---|---|
/rest/v2/entities/ {accessId}/ {typeSignature} | Entity search | Entity creation | Entity update or creation | Entity deletion | Entity update |
/rest/v2/entities/ {accessId}/ {typeSignature}/ {id}/ ({partition}) | Entity return | Entity update | Entity update or creation | Entity deletion | Entity update |
/rest/v2/properties/ {accessId}/ {typeSignature}/ {id}/ ({partition})/ {property} | Property value return | Addition or removal collection elements Only works on collection properties | Property value update | Property value reset to default int, long, double, float, BigDecimal = 0 Boolean = false enums, entities, objects = null maps, lists, sets = empty collection | Property value update |
For more information, see REST v2 /rest/v2.
DDSA with /api/v1
The /api/v1
endpoint allows you to execute any DDSA service request.
URL Endpoints
URL | Description |
---|---|
/api/v1/ {serviceDomain}/{MyServiceRequestType} | Evaluates the service request MyServiceRequest and returns the marshalled response. This is equivalent to calling MyServiceRequest.eval(evaluator).get() using the JAVA API. |
By default, all service requests are mapped to the methods GET
, POST
, and PATCH
.
Method | Description |
---|---|
GET | Used for simple service requests. All properties are encoded in the URL parameters or as custom (so starting with gm- ) headers. The properties must be of type String , int , float , long , double , boolean , Date , decimal , enum or a list or set of the mentioned types. |
POST | Used for more complex service requests. All types are supported. The service request must be encoded in the body of the request, with the mimeType provided in the Content-Type header. |
PATCH | Used in the same manner as POST . |
For more information, see REST v2 /api/v1.
REST Parameters and Headers
Parameters passed in the URL and in the headers are unmarshalled in different entities that drive the behavior of the REST call.
There are 3 types of parameters that can be unmarshalled:
- standard headers, e.g.
Accept
,Content-Type
Standard headers support comma-separated lists:
Accept: application/json,application/xml
.
- custom headers, of the form
gm-parameterName
- URL parameters, of the form
parameterName
When a request is received by the REST API, it is unmarshalled into 2 entities:
- one entity for the endpoint that holds configuration for the endpoint, for example:
mimeType
of the request and supported mime types for the response (withAccept
andContent-Type
),prettiness
of the response ordepth
of the response - one entity for the actual call. For example, the
ServiceRequest
in the case of the/api/v1
endpoint.
Each entity can be populated from both headers and URL parameters.
If both entities have a property with the same name (for example both a service request and the endpoint for /api/v1
have a depth
property) the endpoint property is populated. It is possible to prefix properties to specify which entity should receive the value.
Take a look at the following calls. In terms of result, they are all the same:
-
URL:
/api/v1/com.braintribe.model.securityservice.GetCurrentUser?sessionId=xxx&prettiness=high
Headers:Accept
:application/json
-
URL:
/api/v1/com.braintribe.model.securityservice.GetCurrentUser?service.sessionId=xxx&endpoint.prettiness=high
Headers:Accept
:application/json
-
URL:
/api/v1/com.braintribe.model.securityservice.GetCurrentUser
Headers:Accept
:application/json
gm-service.sessionId
:xxx
gm-endpoint.prettiness
:high
-
URL:
/api/v1/com.braintribe.model.securityservice.GetCurrentUser?sessionId=xxx
Headers:Accept
:application/json
gm-prettiness
:high
-
URL:
/api/v1/com.braintribe.model.securityservice.GetCurrentUser
Headers:Accept
:application/json
gm-sessionId
:xxx
gm-prettiness
:high
Collection Properties
The new REST v2 API allows you to pass collection properties in the URL and as a header. Moreover, when you use the /api/v1
endpoint for service request calls, you can pass collection properties in the body of the request.
-
URL:
/api/v1/foo.bar.MyRequest?collectionProperty=xxx&collectionProperty=yyy
-
Header:
gm-collectionProperty=xxx
gm-collectionProperty=yyy
gm-collectionProperty=xxx,yyy
The following patterns are incorrect and will not work:
-/api/v1/foo.bar.MyRequest?collectionProperty=[xxx,yyy]
-/api/v1/foo.bar.MyRequest?collectionProperty=xxx,yyy
.
You can only pass a set or array of types below:
- numbers: integer, long, float, double, decimal
- Boolean
- date
- enum
- string
- object (only supported if a there is a
TypeSpecification
metadata on the property that specializes the type to one of the above types)
You cannot pass another collection as a collection property.
Try it Out
If you want to experiment with the API for yourself, use our integrated Swagger UI.
For more information, see Using Swagger UI.