general question on designing hosted services (eg, REST servers)

[David Schwartz 426]

I've read some books and even played around with building some REST-based services, but there's something I'm missing. Hopefully someone here can shed some light on this for me.

 

Over the years I've worked on tons of Delphi applications that are classic Client/Server designs with both data-aware controls and more decoupled data management via Data Modules. This is just how Delphi evolved, and all of these old "legacy" apps are build this way.

 

Left to my own devices, I tend to take a different approach, which is that I add Load/Save methods into objects. There's a Load/Save data from/to the back-end, and Load/Save data between an object (or list) and the UI elements it's using. The back-end part is sometimes an INI file, as well as typical DB servers that use SQL or whatever. This is what I'd call a "semi-ORM" approach in that my client code doesn't really know anything about the data storage mechanism, just about objects. The object classes themselves usually have two parts: an object and a collection (list) of them; so I can Load/Save a single object, as well as a whole bunch of them in a list at the same time.

 

In this case, there's usually a pretty close correlation between the on-screen UI elements and fields in the back-end data-store (whatever it is).

 

When it comes to REST-type service interfaces, I've seen different approaches. There's usually a "one vs. many" way to Load/Save data, and this lets you treat the back-end as sort of an extension of the objects. But I've also seen designs that are dominated by lots of small Peek/Poke interfaces that I guess originated with javascript programmers who wanted to get/set values on individual UI elements asynchronous to the rest of the screen.

 

Both approaches ultimately get mapped to a DB made up of tables of records. Some people love to flatten the damn things out and some leave them highly structured. 

 

I guess where I'm confused is this: if I'm building an app from scratch, what's the best way to approach designing the interfaces (or API?) for the back-end services (eg., REST structure)?

 

Most examples I've seen take an existing application that has several DB tables and they simply move them to the server and slap some REST calls in front of them to replace queries to get/set fields and lists of records.

 

I've never really seen a discussion about how you'd approach this if you're really starting from scratch, other than really trivial examples.

 

My thinking is that I prefer to think of the back-end as a "persistent object store" and treat it as a transparent means of adding persistence to individual objects and lists of them. But that's just me. I mean, the fewer "oil-slicks" you need to translate the objects used on the front-end into whatever structure is needed to store them on the back-end, the more efficient and faster everything will flow, right? Cripes, look at how most SOAP interfaces end up working! If you get a bug in one of those "oil-slick" routines, it can be a bear to track down. (I've seen this where someone used StrToInt instead of StrToIntDef and failed to trap exceptions, and it would periodically return invalid but perfectly in-range results that took days to find and fix!)

 

I've been playing around with TMS XData and Aurelius and it makes this approach seem really simple and very intuitive. But this seems to be the exception in terms of what I've found in "real live apps" in the wild.

 

Are there any books or articles that discuss what I'm pointing at here? Of course, feel free to add your thoughts as well, as I'm really curious how people think about this aspect of designing remote services.

Edited January 21, 2020 by David Schwartz

[Lars Fosdal 1792]

I liked the good old RESTful Web Services by Leonard Richardson and Sam Ruby on O'Reilly Media - although it is a bit web-centric.

 

It is indeed complex. Some times peek/poke is the right way, while at other times you do want structured "batch" updates.

The design needs to be governed by the nature of the API usage, the amount of concurrent use, the complexity of the data.