Application Development Meanderings

If you use "readers" similar to play's json reader framework, you know that its a nice framework to compose your json converters. There is a similar framework for reading XML from lucidchart called xtract. xtract only provides XML reading. Its very similar to play json. Many of the examples that demonstrate the play json or xtract library are fairly simple and did not help me understand how to compose readers that need to have alternatives. For example, an XML fragment may have an element called   Fault   or an element called   Data   and you want to compose a reader that automatically handles both in one reader instance. How do you do that? Here's some scalatest examples that show one way to do that. You have some choices about how to navigate and how to compose so pay special attention to the details in the tests. I prefer to compose by using readers at the top element and use and/or on the builders, but you can choose to do it anyway you wish. The code may b

There is a need in web client applications to query a server. Many people have been turned off by REST as the basis for an API because it requires them to navigate the explicit or implied schema on the server through a series of REST calls. Often the REST URL format is adhoc. The REST calls reflect the data architecture on the server and require orchestration into the object graph to retrieve the data. A more formal adherence to REST would include links in the response that eases this type of navigation but many RESTful APIs do not follow this model. Along time ago, server side applications using ORM or just SQL tools ran into "how to pull an object graph" problem and never really solved it robustly although solutions exist. If the graph request was rigidly programmed into the object description, you would never be able to pull an ad-hoc object graph (that was not programmed into the ORM object annotations) easily and your client code would be littered with network database