Do you have a more robust example that illustrates how to handle resource queries for a RESTful API using persistent state objects? The two issues I’ve run into are parsing the path parameters and then formulating the query for the persistent state objects.

Here’s the type of query that needs to be handled: curl -X GET -G “http://localhost:12007/ticket/status,description?status=Submitted&creationDate.gt=2013-05-01”

I’m not sure whether I understand your issue correctly. Do you have problems getting the query parameters, such as status? If so, these parameters are found in the getParameters parameter (see http://docu.e2ebridge.com/HTTP+Service or http://docu.e2ebridge.com/Plain+HTTP+Service).

The question is not so much on parsing the parameters but rather what is the recommended way to model handling a query that involves date types with gt, gte, lt, lte? And how to handle attribute filtering?

The Persistent State Adapter identifierCondition requires an explicit logical date expression. How to handle a RESTful request like the following:

unfortunately, you cannot build state queries dynamically today. In theory it is possible to query the state database directly by using SQL, but we don’t recommend it. One reason is, that we might change the DB schema. Another reason is, that it is not completely trivial to build queries for search keys because we store them in an EAV table.

Regarding your second question: we don’t support filtering of persistent state attributes either.

All things considered, I would store your ticket resource in a relational database. Then, your requirements are easily implemented.

That’s too bad on both fronts. The persistent state modeling pattern works very well for the TMF RESTful APIs that I’m working to implement using the E2E Builder.

Being able to dynamically build queries for the PersistentStateAdapter would be make handling types like date much easier. It seems it would be pretty straightforward to build the query as a string using ActionScript and then to pass that query string into the PersistentStateAdapter.

Reverting to using a relational database to manage the tickets would make it easier to filter attributes but would lose the state machine features of the persistent state modeling pattern.

Both of these requirements are typical of a RESTful API pattern, sure would be nice if they were supported by the persistent state adapter.