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
Once authenticated,
The response returned from the above request:
Dependency-Free
You can, of course, also consume the REST API without any strong typing or reference to our DTO classes.
Below is a code sample showing how to consume the REST API to logon and retrieve a debtor record with nothing more than a reference to the Newtonsoft.Json nuget package for deserialisation. This sample also uses the .NET WebClient, but manually sets the SessionId cookie.
using (var webClient = new System.Net.WebClient())
{
// Authenticate
webClient.QueryString.Add("username", "api");
webClient.QueryString.Add("password", "password");
string responsebody = webClient.DownloadString("http://localhost/auth");
// Above returns something like this: {"SessionId":"0hKBFAnutUk8Mw6YY6DN","UserName":"api","DisplayName":"","ResponseStatus":{}}
// Deserialise response into a dynamic - below requires the Newtonsoft.Json nuget package
var authResponse = Newtonsoft.Json.JsonConvert.DeserializeObject<dynamic>(responsebody);
var sessionId = authResponse.SessionId;
webClient.Headers.Add(System.Net.HttpRequestHeader.Cookie, string.Format("ss-id={0}", sessionId));
responsebody = webClient.DownloadString("http://localhost/Debtors/0000000061000000001V");
}
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.