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.
Related
So last year, someone introduced me to an off-the-shelf database server package/ technology that would take a request from a client and would serve up the information in a JSON format that was defined in the request. Having previously had to develop mobile client applications using apis designed for websites, this seemed like a wondrous thing. Being able to make one call and receive only the data you asked for and in the format that suited your code would be a godsend.
Unfortunately, I didn't get the opportunity to work directly with the technology and I have subsequently forgotten what it was called. Neither Google nor StackOverflow has been my friend. It's difficult to formulate the search terms to get the right hit I suppose. Nobody I currently work with has heard of this and I have lost contact with the people who originally introduced me to it.
It's driving me nuts. Does anyone know the name of this package?
The technology I was thinking of was GraphQL.
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/
I'm designing the architecture for a new web application.
I think that communications between the backend (server) and the frontend should be JSON only.
Here are my arguments:
Its the client responsibility to manipulate and present data in its own way. The server should just send to the client the raw information needed.
JSON is lightweight and my application might be used by remote clients over poor mobile connections
It allows multiple front-end developments (Desktop devices, mobile
devices) and has the potential to create an API for other developers
I can't see any counter-argument to this approach, considering that we have internally the frontend skills to do almost everything we need from raw JSON information.
Could you provide counter-arguments to this JSON-only choice so that I can make a more informed choice?
There must be some as a lot of backend frameworks (think about the php ones) still advertise HTML templating to send HTML formatted responses to the clients.
Thanks
UPDATE: Even though I researched the topic before, I found a similar and very interesting post: Separate REST JSON API server and client?
There are many front end based framework already in market which support a Json very efficiently,some of them are backbone,underscore,angular etc.Now if we talk about backend,we generally use REST based communication for such type of application.So i think this type of architecture already exits in market and working very well,specially if i talked about mobile based application.
Although this question is dead, I think I should try to weigh in.
For all the reasons you stated and more, communication between the back-end and front-end via only JSON files is maybe the best way available, as it provides a more compartmentalized structure for your web application, and at the same time drastically reduces the data sent over your users' connection.
However, some drawbacks that are a direct consequence of this are:
Need for a lot more JavaScript front-end development (as the HTML structure is not being sent by the server and needs to be created in the client)
It shifts the pressure from the server to the client, thus there is more JavaScript for the client to run (this can sometimes be a problem especially for mobile users)
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
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.