Authenticating
Most routes will require authentication. This is performed by invoking the /auth route and passing the username and password of a Jiwa user. A successful authentication will return an authentication response containing the SessionId. All subsequent requests will need to provide the SessionId as the value for the cookie "ss-id".
The response returned from the above request:
{"SessionId":"6w1nLX8r0sIrJHClX9Vj","UserName":"Admin","DisplayName":"","ResponseStatus":{}}
Example of calling a route
This example shows how to retrieve a debtor record for a known DebtorID.
The response returned from the above request will be a json document representing the full debtor business logic - see the meta data page for the DebtorGETRequest for more detail.
Stateful Interaction
While typically interactions with a REST API would be stateless, it is possible to interact in a stateful way by passing the Request header "jiwa-stateful" with the value of "true".
When stateful requests are received, the server caches the appropriate business logic and subsequent requests will interact with that in-memory object. This allows the consumer to perform actions like building a sales order without it being saved to the database until it is ready to save it.
Stateful requests will be committed to the database when a SAVE Request is received. Pending changes can also be discarded with an ABANDON Request.
Below is an example of a stateful interaction with the Debtors - the object is statefully retrieved, and updated until a SAVE Request is sent.
var client = new ServiceStack.JsonServiceClient("http://localhost"); var authResponse = client.Send<ServiceStack.AuthenticateResponse>(new ServiceStack.Authenticate() { provider = "credentials", UserName = "api", Password = "password", RememberMe = true }); // Read a debtor client.Headers.Add("jiwa-stateful", "true"); var debtorGETResponse = client.Get(new DebtorGETRequest { DebtorID = "0000000061000000001V" }); // Update debtor var debtorPATCHResponse = client.Patch(new DebtorPATCHRequest() { DebtorID = "0000000061000000001V", Name = "My new name", CreditLimit = 1000 }); // Update some more fields debtorPATCHResponse = client.Patch(new DebtorPATCHRequest() { DebtorID = "0000000061000000001V", Address1 = "SE2L10 100 Walker Street" }); // Save the changes var debtorSAVEResponse = client.Get(new DebtorSAVERequest() { DebtorID = "0000000061000000001V" }); }
When the server creates the business logic object, it is stored in a collection associated with the users session (this is actually a property of the Manager class - the ObjectDictionary). Subsequent stateful requests for the same type (eg: Debtor Maintenance operations) will retrieve any existing business logic for the same record, otherwise a new business logic instance is created.
This means two subsequent stateful operations for different debtors will result in two business logic objects created by the server, and they will remain independent of each other.
Conversely, two subsequent stateful operations for the same debtor will result only one business logic object created by the server, and the second operation will be working on the same business logic instance as the first operation.