开发者

What types of API do you offer with your Delphi application?

开发者 https://www.devze.com 2023-01-24 20:23 出处:网络
We have a 3-tier Delphi application written using RemObjects DataAbstract. Many of our c开发者_JS百科ustomers are asking for an API so they can interact with it using their own applications.

We have a 3-tier Delphi application written using RemObjects DataAbstract. Many of our c开发者_JS百科ustomers are asking for an API so they can interact with it using their own applications.

The API must allow the clients to call methods with various parameters and return results ranging from simple parameters to whole datasets.

What types of API can you recommend and how difficult are they to implement?


Since you've written your application using RemObjects DataAbstract then you've got just about everything you need already waiting for you in your application.

RemObjects DataAbstract includes the RemObjects SDK which is one of the most flexible and easy ways to build an API available. The RemObjects SDK lets you expose methods methods to your customers in a multitude of ways from native binary RemObjects calls, to XML-RPC, to JSON, to SOAP, to a local DLL, to Windows Messages, to Named Pipes... even via SMTP/POP.

The beauty is that you'll be able to design one API and then easily expose it to your customers via any or all of these different mechanisms. Just design your API methods, then ask your customer how they'd like to be able to consume it, chances are RemObjects have a message/channel combination that matches their request.


  1. Publish the API as functions in a DLL. Easy enough to code, but limited by the DLL limits (only plain functions, etc.). Not easy to call from scripts, for example
  2. Publish the API as COM objects. A bit more complex to implement (especially if you never used COM before), but very flexible. Can be easily called from scripts, if needed.
  3. Use a standard generic RPC mechanism like SOAP or REST. Better suited for server, not difficult to implement, requires a "listener" active to receive the calls
  4. Use your own protocol to communicate. Longer to implement, can be faster than SOAP or REST, but requires also more work on the customer side.


Besides the plain business logic API, I think it will be also a big advantage if the application offers APIs for generic tasks like:

  • logging / audit trails
  • monitoring (performance, statistics)
  • rights administration
  • basic administration (shutdown / go to maintenance mode)
  • messaging (send notifications to users or applications)
0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号