+Dorin Duminica suggested to add http/s request capabilities to JsonToDelphiClass generated units. I came up with a solution that involves new base class for all stub classes. That base class will offer CRUD methods. My ideia is to be REST compatible solution, based on Indy (micro REST I think?). May be Remy Lebeau can say more?

+Dorin Duminica suggested to add http/s request capabilities to JsonToDelphiClass generated units. I came up with a solution that involves new base class for all stub classes. That base class will offer CRUD methods. My ideia is to be REST compatible solution, based on Indy (micro REST I think?). May be Remy Lebeau  can say more?

I want to keep it one unit only (i.e. no external units). The base class will be named like the unit with a 'T' in front. All descendant classes will reintroduce the HttpGet method to return concrete instance.
HttpPost and HttpPut will send the serialized object as payload (I forgot to set the Content-Type in PasteBin). HttpDelete does not have payload since the resource is specified in the URI. It stays a little bit strange in that picture, but I want to keep it.

I've tested HttpGet method and it seems to work nice.

I will appreciate your opinion about the idea and the implementation here: http://pastebin.com/2s6nprXP 
http://pastebin.com/2s6nprXP

Comments

  1. Jeroen Wiert Pluimers btw the same applies to the serialization/deserialization. I will provide more generic approach and will not tie serialization to a particular framework. This will make the whole thing more backwards compatible.

    ReplyDelete
  2. Jeroen Wiert Pluimers this is the so called DI, isn't it?

    ReplyDelete

Post a Comment