I have never used json before, and don't care anything about it except I now have a requirement to access an application through json-rpc.
I have done searches on "erlang json" which returned everything from proposed erlang bifs to mochijson to whatever. Thing is, I have yet to find any documentation or example using any of this stuff to do what I need to do, which is control another app through json-rpc. Most of the docs and examples I've seen have dealt with conversions and mappings from erlang data types to json and back. In fact, docs seem to go so overboard with enthusiasm for representing "language X" terms in json that I've often wondered whether there was something I've missed along the way. Thus far the topic has failed to stimulate any blood flow towards certain regions of the body, but whatever - it is what it is.
WHAT I DON'T WANT
I DON'T care about javascript, and I DON'T care about doing anything related to json-rpc from javascript or the browser.
WHAT I WANT
To use json-rpc from erlang SERVER SIDE to control an app SERVER SIDE.
At any rate...
1) Can someone point me to some docs and examples showing erlang using a json-rpc library to control or access another app?
2) Can someone recommend a library or libraries to do this? Since I am currently using yaws (or attempting to), my first choice would probably be yaws since it appears to have some json built-in. Thing is, the only yaws examples I saw were focused on using javascript code browser side to trigger some kind of json-rpc thing server side, and I don't want to do that.
At any rate, I'll accept the first thing that can do what I want and has documentation showing it being used that way.
Thanks.
WHAT I WANT
To use json-rpc from erlang SERVER SIDE to control an app SERVER SIDE.
Did you mean There is a json-rpc server implemented with erlang? and you want control an app behind that json-rpc?
Lets say there is a json-rpc server at "https://10.11.1.100:8006/json-rpc/"
And you can use any program language to access that url by http library, for example python's http module with some data for post query or just get query depend on what your json-rpc server provided.
Let's say there is a "Getfruit" and "Putfruit" method provided on json-rpc server for control the back app to load fruit to database.
Then you can use python http library start a get query to "https://10.11.1.100:8006/json-rpc/Getfruit/3", then the server will return a json data contains fruit(ID is 3) detail.
if you want control back app by sending some data to it's database then use post method on "Putfruit" path.
So, this is a simple example for how use json-rpc server.
If I misunderstanding you, if you want how use erlang to control a app through json-rpc server, then just use erlang's http library
Related
Could anybody explain advantage of using json-rpc over json-api and vice-versa? First and second format are JSON-based, but where I should use one, and where is another?
Note: I may come across a little biased. I am the author of the Json-RPC.net server library.
Json-RPC is a remote procedure call specification. There are multiple libraries you can use to communicate using that protocol. It is not REST based, and is transport agnostic. You can run it over HTTP as is very common, you can also use it over a socket, or any other transport you find appropriate. So it is quite flexible in that regard. You can also do server to client along with client to server requests with it by hosting the RPC server on either the client or the server.
Json-API is a specification for building REST APIs. There are multiple libraries you can use to get started with it. In contrast to Json-Rpc it requires you to host it on an HTTP server. You cannot invoke functions on the client with it. You cannot run it over a non-http transport protocol. Being REST based, it excels at providing information about Resources. If you want an API that is based around the idea of Create, Read, Update, Delete on some collections of resources, then this may be a good choice.
Json-API is going to be better if your API is resource-based, and you want your API to be browsable by a human without setting up documentation for it. Though that human would likely need to be in the software engineering field to make any sense of it.
Json-RPC is going to be better if your API is function based, or you want the flexibility it provides. Json-RPC can still be used to manipulate Resources by creating Create, Read, Update, and Delete functions for your resources, but you don't get the browsability with it not being REST based. It can still be explored (not browsed) by a human by generating documentation based off of the functions you expose.
A popular example of something that uses Json-Rpc is BitCoin.
There are a lot of popular REST-based API's and Json-API is a spec with a bunch of tools to help you do REST right.
--
Note: Neither of those (Json-RPC, or Json-API) are good when you consider for developer time, performance, or efficiently using network resources.
If you care about performance, efficiency, or developer time then take a look at Google's gRPC which is fantastic in those regards, and can still reduce developer time more than using a REST API as client and server code can be generated from a protocol definition file.
I'm trying to build my first Sproutcore App and I struggle to connect it to a MySQL-Database or any datasource other than fixture. I can't seem to find ANY tutorial except this one from 2009 which is marked as deprecated: http://wiki.sproutcore.com/w/page/12413058/Todos%2007-Hooking%20Up%20to%20the%20Backend .
Do people usually not connect SC-Apps to a Database? If they do so, how do they find out how to? Or does the above mentioned tutorial still work? A lot of gem-commands in the introduction seems to already differ from the official Sproutcore getting-started-guide.
SproutCore apps, as client-side "in-browser" apps, cannot connect directly to a MySQL or any other non-browser database. The application itself runs only within the user's browser (it's just HTML, CSS & JavaScript once built and deployed) and typically accesses any external data via XHR requests to an API or APIs. Therefore, you will need to create a service wrapper around your MySQL database in order for your client-side app to be able to load and update data.
There are two things worth mentioning. The first is that since the SproutCore app contains all of your user interface and a great deal of business logic, your API can be quite simple and should only return raw data (such as JSON). The second is that, I should mention that the client-server design, while more tedious to implement, is absolutely necessary in practice, because you can never trust the client side code, which is in the hands of a possibly nefarious user. Therefore, your API should also act as the final gatekeeper to validate all requests from the client.
This tutorial I found helped me a lot. Its very brief and demonstrates how to implement a very simple login-app, how to send post-requests (triggered by the login-button-action) to the backend-server and how to asynchronously process the response inside the Sproutcore-App:
http://hawkins.io/2011/04/sproutcore_login_tutorial/
My application uses GWT-RPC to communicate to the server. Is there anyway to transparentlly serialzie my data using JSON without changing the RPC layer?
IMHO this could be acheived by changing the serializers and using autobean codex in the UI.
Why do I need that?
I want to make cross domain RPC calls
I want to call the server side from a non GWT-app without providing an extra layer in server side.
UPDATE I just stumbled upon http://code.google.com/p/gerrit/source/browse/README?repo=gwtjsonrpc which is actively maintained (as it's part of Gerrit, the code-review tool used by the Android team)
Have a look at http://code.google.com/p/gwt-rpc-plus/ but it's no longer maintained...
If you really need it and don't want to move away from GWT-RPC, then replacing GWT's serializers should be possible: that's exactly what deRPC (com.google.gwt.rpc) does re. standard GWT-RPC (com.google.gwt.user.rpc), but it needs to do a bit more than that (namely: generate the serialization code for the client-side, as there's no reflection at runtime).
This going to be a hard task. I don't think the changing of serializers will work, GWT-RPC serializers are working with input as with a stream (basically data sent from server are in fact in JSON format, but they can be parsed only by GWT-RPC). You will have to create totally new generator, which will create code for parsing and object serialization/deserialization. AutoBean framework might be very helpful in this case. In the end you should be able to to migrate from GWT-RPC serialization to some other protocol without actually changing current code, which is using GWT-RPC services.
The biggest problem is cross-domain messaging. Normally you would use JSONP, but the problem is that JSONP basically allows only GET requests, if you need send a lot of data to the other server, you might not be able to fit everything into single requests. You can solve such problem with cross domain document messaging (e.g. you will open iframe, which will load special communication javascript from remote server, and you will use this iframe as proxy for your service via postMessage) , but this feature is not supported in IE7.
This may be a terribly uninformed question, brace yourself. A company I'm working with has given an 'API' that I can use to access orders, however, there are only two real commands, getorders and getorderdetails. These commands are put in the format of www.server.com/path/to/the/orderapi/getorders/UniqueKey/
If I go to that web address, I'm prompted for a username and password, and once authenticating, get presented with a page of JSON formatted order details, contained in the body of the html page. I would like a service to check this information and create orders in our CRM based on it, is there an obvious way to access it without the browser/client interaction?
Update: We intended to Use BizTalk to consume this resource but after a bit of research and experimenting have decided to use a different service (WDSL), mainly because BizTalk doesn't seem to have terribly great support for Restful webservices. If anyone with more knowledge of the subject would like to chime in that's fine by me.
Update 2: Noticed that (a since deleted) thread on stackoverflow is basically a feedback thread of biztalk 2009-r2, and one of the requests is support for restful web services, so I don't think there is a graceful solution for restful services in BizTalk 2009.
Use your language of choice, along with some library that speaks HTTP, and start hacking away?
In PHP, you'd use the build-in cURL library to make the HTTP requests. You'd grab the JSON data, run it through json_decode() to create native PHP datatypes, and then operate on them at will, doing whatever you need to do to create orders in your CRM.
Can anyone explain to me the benefits of using XML-RPC over a straight HTML Form ?
On first glance, they seem to accomplish the same thing.
The XML-RPC is "formatted" using XML, but you can do the same in a form (think textbox).
I have an app that takes data from a script that runs on the client PC. The output from the script is XML. Currently it is submitted to the app (PHP using CodeIgniter) via a form POST. I have been told to look at using XML-RPC, but I am trying to understand "why"...
I primary benefit of XML-RPC is that you don't have to write any (or nearly any) glue code to get remote processes to communicate. There are a wide variety of XML-RPC client libraries available for many languages. In the case that you have a rich API of functions, XML-RPC can be a very easy way connect remote processes to that API. Performing the same task with a plain www-form-encoded POST will require you to convert an API to a form and dispatch requests into api calls. There are a few systems that can help with that, but it is certain to be more difficult than just exposing the API through XML-RPC.
On the other hand, if (as it sounds) you already have a rich API exposed through plain form encoded requests, It's hard to justify the work of porting both client and server to another interface.
If you mean encoding data in the www-form-encoded (or "query string style") format vs POSTing XML-RPC, it's really a matter of taste. Some people prefer to use XML for everything.
XML-RPC is a bit dated, in my opinion. Unless you're talking about a different protocol, this is the one that preceeded SOAP. I wouldn't use it at all. Instead, I'd either use a SOAP-based service, or a REST-based one.
HTML forms are not comparable to XML-RPCs.
You use HTML forms to get some input data through a WebPage, while you use XML-RPC to execute remote procedures using XML.
Usually you will use XML-RPC for a process without a UI trying to execute some procedure remotely.