The modern software development landscape is a very complex thing and it changes very fast, as well. New programming languages are created and new application frameworks are released literally every week. Still, most applications need to somehow communicate with the world – regardless of which exactly language or framework is used to create them.

Unfortunately the first industry attempt to provide a simple clean and cross-platform communication platform, SOAP, ultimatively failed and turned into a complex beast. Then the second attempt was made and a REST paradigm was born. We won't discuss the SOAP vs. REST pros and cons here, still personally I think that REST is a way easier to work with.

Of course Remoting SDK always provided its own way for handling communication, but only for those platforms it directly supported. And while it offered SOAP as a fall back, there was no way to communicate with RO servers via REST. Until today.

HttpAPI

Allow me to present a new feature in Remoting SDK called HttpAPI. HttpAPI is a simple way to add HTTP-based interfaces to your existing Remoting SDK servers, or to develop new servers. Considering the open and well documented communication protocol used, client applications can be created on a vast array of languages and platforms, including those where a dedicated Remoting SDK client library is not available.

Http API Server and its Swagger definition

To name but a few features of HttpAPI:

  • Automatically generated OpenAPI (some call it 'Swagger') service definition that allows to create client applications for any language and platform that is supported by the code generation tools, from C# to Go or React Native
  • No Remoting SDK client-side libraries are needed to communicate with the server. Any platform and language that can send out a HTTP request and receive the answer can talk to a Remoting SDK server now
  • Only minimal changes are required to make the existing SDK server apps able to server HttpAPI request
  • Fast and reliable Remoting SDK server-side code
  • The overhead compared to classic RO servers is minimal and is mostly down to request text parsing. This overhead is barely, if at all, noticeable considering the inevitable network latency
  • Methods exposed via HttpAPI support the same parameter types as ordinary Remoting SDK service methods do
  • Service method parameters can be passed as a part of the URL, via the query string or via the request body

This is the first of a series of posts we plan to publish about this exciting new feature. The next one will show how to create a HttpAPI-enabled server application and in the third one I will create a client application for this server and explore different authentication strategies like good old password-based authentication, Basic authentication and then we'll take a look at a way to utilize a 3rd-pary authentication services.

PS: And last but not the least: I'd like to thank our long-time RO user Günther Schoch for his efforts and support that made this feature come live.

PPS: Does that make Remoting SDK for JavaScript obsolete? Both yes and no. You no longer need it if you want to communicate with a Remoting SDK server from JS. You still need it if you need to communicate with Data Abstract servers or use some advanced SDK features like server-sent events.

Out Now!

HttpApi is available in Remoting SDK 9.3, which is out now. You can read more about how to use it in the docs.