REST versus JSON-RPC / what does RemObjectSDK support in the future?

Remoting SDK
1

Hi

As I understand the RemobjectSDK does implement JSON-RPC by TROJavaScriptHttpDispatcher and JSONMessage.
(Remark: JSON-RPC - Update to 2.0? that the supported spec 1.1 is outdated but this is not the major problem)

But the Today world is REST (and not JSON-RPC). See statements as


https://developer.atlassian.com/display/JIRADEV/JIRA+JSON-RPC+Overview
An in the real business world the companies asking us to provide a REST-Server functionality will not accept JSON-RPC.

Discussions as http://stackoverflow.com/questions/14645022/can-remobjects-sdk-parameters-be-passed-via-the-uri/14648334#14648334 do show that we are not the only ones with that problem.

Now the logical question: REST versus JSON-RPC / what does RemObjectSDK support in the future?
IMO it makes no sense that each one tries to solve this problem by inheriting and adapting some functionality!

best regards

GĂźnther

3 Likes
2

GĂźnther,

once in a while, people as about supporting REST in ROSDK. the problem is — what is REST? REST really is just a fancy name for HTTP. You call a URL, and you get some arbitrary data back, could be any format (XML, JSON), and any structure.

REST doesn’t really fit into ROSDK, which abstracts methods calls at a much higher logical level, and i really wouldn’t know what we’d implement in terms of REST support that isn’t, really, just a plain HTTP client component — of which there are hundreds out there.

Maybe i’m missing something — and if so, i’d love to see a concrete example of how you see REST fitting in with what RO does (“define methods, implement them on the server, call them from the client, without worrying about the inbetween, too much”)

thanx,
marc

3

Hello Marc

thank you for your detailed feedback. You are right on the REST consumption by a client. There are n-models without any useful definition (see http://en.wikipedia.org/wiki/Web_Application_Description_Language where a WSDL language equivalence was described but dropped later)

But links as http://www.layer7tech.com/tutorials/rest-to-soap-remapping describe the task to provide a WSDL based WebService as Rest. This is actually the use case I try to solve.

But I agree, there would be a lot to specify for the mapping:

a) what http-method shall be used (POST, PUT, GET) on an individual webservice method
b) which get-parameter shall go to the direct HTTP parameters and which shall be provided within a JSON structure.

I assume you suggest to follow the JSON-RPC route?

a) If yes: Any plans to support version 2.0 fully?
b) and how do I document the calls?
(I checked the Service Builder several times but have not found any Docu option showing the JSON-RPC syntax)

best regards

GĂźnther

4

Hello!

Could you briefly describe your original task (i.e. ‘we have a real estate db and want to expose it to our clients via webservice’). Why are you considering json-rpc vs rest options but not SOAP for example?

Yes, there are such plans, but very low priority. The reality is, 99% of cases are RO SDK server + RO SDK client and 1.1 is enough for this. Also RO SDK for JavaScript supports binary message in all modern browsers. Speaking of non-RO servers/clients, SOAP message seems most used according to our support statistics, so maybe you should consider it.

Sorry, I don’t quite understand the question. Service builder has ‘document this operation/document this parameter’ buttons on the service page and the text you’ve entered there is properly stored in the RODL file.

5

Could you briefly describe your original task (i.e. ‘we have a real estate db and want
to expose it to our clients via webservice’). Why are you considering json-rpc vs rest
options but not SOAP for example?

For one of our products (energy industry) the SOAP/WSDL-Server is nice but some elements should be provided as well via REST to be implemented into a Web-Server portal.

But actually it’s all “politics”. See https://www.codecentric.de/files/2011/05/web-services-versus-rest.pdf (sorry - it’s in German but summarizes exactly the situation of “evangelism”). I certain environments we cannot decide what is technically the best but have to provide what the customer does want.

… SOAP message seems most used according to our support statistics, so maybe you should consider

for our own projects for sure. Again - it’s the area were the customer has some “REST-evangelists” in the architecture team.

Sorry, I don’t quite understand the question. Service builder has
‘>document this operation/document this parameter’ buttons on the service
page and the text you’ve entered there is properly stored in the RODL file.

what I expected is a useful documentation for the “JSON-RPC client implementation”. I get this more or less for the WebService implementation by “ServiceBuilder → View → Docu”. This document we use to deliver with our RemObject-Based WebServer. That includes examples as

Oxygene Syntax:method EMailService.Send(const AMessage: TEMail_Message);
C# Syntax: public void EMailService.Send(TEMail_Message AMessage);

But what shall I give to a the JSON-RPC client developer?

regards

GĂźnther

6

Re REST and politics - got it. Unfortunately, I can only second Marc on this, REST doesn’t really fit into RO SDK ideology.

Re JSON-RPC - suggested way for web apps is to use RemObjects SDK for JavaScript. http://wiki.remobjects.com/wiki/Calling_RemObjects_SDK_Servers_from_JavaScript
Of course, it’s possible to build JSON request object manually and send it via AJAX without using RO/JS but I’m afraid we don’t have user documentation on this.

7

I have same requirement for JSON-RPC call. I want to use base on ROServer services with ROClient and base on REST request application both (Now, I have a base on REST services application, but it is not RO client application).