I am new to Enyo and web services. I am looking to build a web page with Enyo that will require use of Echonest. Can anyone help me understand how to connect to the Echonest service from inside Enyo and whether to use SOAP, REST, or something else?
I assume you are talking about the Echo Nest found here: http://the.echonest.com ?
Briefly glancing at their API, you may not have to use SOAP or REST since everything is accessible with simple GET requests through the Web service. It looks like the hardest part of using their API will be generating OAuth signatures for authenticated requests.
As far as the enyo.WebService, http://enyojs.com/api/#enyo.WebService, goes, you should be able to include the kind, set the URL and call the .send() method on it. Then you response handler would get the data back (I recommend json) so you can do what you will with it.
Another option would be to use enyo.Ajax, http://enyojs.com/api/#enyo.Ajax, directly. enyo.WebService wraps that and provides a familiar (to Enyo 1 developers) way to use it.
Related
When I'm tasked with dealing with connecting to web services, I've always found the appropriate .wsdl file, ran WSDL2Java.bat, and incorporated those Java files into my Java project. Then I've successfully completed my project that needs to access data via web services.
My question is, are there other ways to use the .wsdl file to access web services? ( I'm not talking about creating classes for different languages ). For example, I have documentation describing one company's web services. The examples it shows in it's documentation are essentially dumps of HTTP Post requests. Is this "web services"? It looks to me that the .wsdl file is merely used as a reference to make the correct Post requests. I could just make text templates and plug in the right values, and send them out, right? I really feel like I'm missing something here.
Am I a web-services illiterati?
To call a SOAP web service over HTTP you just need to send it a properly formatted XML with a POST request. That's it! How you build the request is irrelevant as long as it conforms to the SOAP protocol and the payload corresponds to a proper web service operation that exists on the particular web service you are calling.
But how do you know how to build the proper payload?
The web service needs to have some sort of documentation otherwise you don't know what to put inside the XML. The documentation can be whatever you like as long as people can use it to build valid requests. WSDL fits this criteria but has an extra advantage: you can feed it to a tool that generates code. That code knows how to handle all the SOAP details and exposes objects and methods to your application.
What would you prefer? Generating code from the WSDL in a few minutes and be able to call whatever operation on the web service or, build the requests and parse the responses by hand and spend hours or days doing so. What would your boss or company prefer? :)
It looks to me that the .wsdl file is merely used as a reference to make the correct Post requests. I could just make text templates and plug in the right values, and send them out, right?
Right! But you also have to consider your productivity as an employee in one case as opposed to the other.
My team and me are currently working on quite a large project. We are working on an online game, which will be accessible (for the moment), in two ways:
-Via a web browser, an application full JavaScript(client-side), full Ajax (basically meaning that the UI will be managed in JS client side).
-Via an iPhone application (the UI will be managed by the application itself).
Between the two different applications, the core logic remains the same, so I believe (I could be wrong), that the best solution would be to create a web service (if possible using standards such as RESTful or Rest) capable of perming all necessary operations.
Following this logic, I have encountered a problem: the authentication and identity management of the user. This poses problem as the applications users need to be authenticated to preform certain operations.
I’ve looked into WS-security, but this obviously requires passwords to be stored, unencrypted on the server, which is not acceptable!
I then looked into Oauth, but at first glance this seemed like a lot of work to set up and not particularly suited to my needs (the way that applications have to be accepted does not please me since it will be my application and my application only using the web service, not any external application).
I’ve read and heard about a lot of other ways to do what I want, but to be honest, I’m a little confused and I don’t know what information is reliable and what isn’t.
I would like to note that I’m using symfony2 for the backend and jquery for the client side JavaScript.
Furthermore, I would like a detailed, step-by-step response, because I really am confused with all that I have read and heard.
Thank you for your time, and I hope someone can help me as it’s quite urgent.
Good evening
I'm not entirely sure if this answers your request, but since the UI will always be handled on the client side, I think you could use stateless HTTP authentication:
This is the firewall in security.yml:
security:
firewalls:
api:
pattern: ^/api/ # or whatever path you want
http_basic: ~
stateless: true
And then the idea basically is that on the server, you use your normal user providers, encoders and whatnot to achieve maximal security, and on the client, you send the HTTP authentication headers, for example, in jQuery:
$.ajax("...", {
username: "Foo",
password: "bar"
});
Please note that since the authentication is stateless (no cookie is ever created), the headers have to be sent with every request, but, I figure, since the application is almost entirely client-side, this isn't a problem.
You can also check the Symfony2 security manual for further information on how to setup HTTP authentication. Also be sure to force HTTPS access in your ACL, so the requests containing the credentials are secured (requires_channel: https in your ACL definitions).
this is only loosely programming related.
I wrote myself a shellscript, that extracts all acronyms from a text and writes them to a file. Now I would like to process that file to add the definitions.
My first google hit suggested using curl and the dict:// url scheme. However I am behind a proxy, which does not seem to allow that.
Does any of you know a service that is similar to the dict:// but is provided via HTTP?
Ideally it would be restful since messing around with SOAP seems somewhat bloated for this task.
There are plenty of Dictionary API services listed on http://www.programmableweb.com
I am writing an interface for our VXML application that will allow access to a SOAP service.
Because of the difficulties inherent in trying to use javascript to make SOAP calls and the limitations of VXML, as in making external resource calls are pretty much limited to HTTP requests, GET and POST.
I designed a java servlet that would act as a service provider to the VXML application. It can call this servlet with arguments indicating the web service type, the method name to invoke and the arguments to pass to it. The servlet then makes the appropriate web service call and returns the response in a standardized VXML document response.
The issue is I severely underestimated how difficult SOAP really is. I thought I could just simply construct the soap call and do it in java, however its looking to me like this is something a little more involved, requiring things like Apache Axis2.
I read somewhere that listeners for Axis could be HTTP servlets, which sounds a lot like what I am doing already.
Am I re-inventing the wheel here?
Is there any suggestion out there for me as to how to do this better?
I am pretty invested in the way I'm doing it now and so would be very receptive to an easy way to accomplish the SOAP call and process the response from a jsp servlet.
EDIT - After taking the advice here I've delved a little further into Axis.
As it turns out, Axis2 is Apache's third generation of Apache SOAP. Whats unfortunate about this is that after extensive searching I cannot find a single solitary place where the original Apache SOAP implementation can be downloaded.
I might not care if:
A) Axis would allow me to integrate a few jars and jsps rolled
into a standalone WAR app
B) everything .. i mean everything up to this point has been done using
examples from ApacheSOAP (the book i was using, the code I've
written thus far .. everything).
So I google some more thinking .. hey, there has to be some kind of stand alone library for Java that would just simply allow me to make a single solitary simple SOAP call and parse the results.
But no, no such luck!
Apparently if you want to use Java and SOAP you have either the gigantic incomprehensibly thick and complicated axis or .. you roll your own soap implementation from the ground up. I am so burned on this. I don't get why soap is so wonderful given the last 7 13 hour days I've spent just trying to get a simple hello world request to work from JSP.
A library like Axis is definitely the solution, you do not want to attempt to build/parse SOAP messages on your own.
Look at using wsdl2java (another link, and another) to create client proxies for which you can invoke the web services. This will generate a bunch of Java code which you can call into from your code, and then Axis will handle packaging your arguments into XML messages, sending it across the wire to the server, de-serializing the response, etc.
I'd like to start moving our application business layers into a collection of REST web services. However, most of our Intranet has been built using Classic ASP and most of the developers where I work keep programming in Classic ASP. Ideally, then, for them to benefit from the advantages of a unique set of web APIs, it would have to be called from Classic ASP pages.
I haven't the slightest idea how to do that.
You could use a combination of JQuery with JSON calls to consume REST services from the client
or
if you need to interact with the REST services from the ASP layer you can use
MSXML2.ServerXMLHTTP
like:
Set HttpReq = Server.CreateObject("MSXML2.ServerXMLHTTP")
HttpReq.open "GET", "Rest_URI", False
HttpReq.send
#KP
You should actually use MSXML2.ServerXMLHTTP from ASP/server side applications. XMLHTTP should only be used client side because it uses WinInet which is not supported for use in server/service apps.
See http://support.microsoft.com/kb/290761, questions 3, 4 & 5 and
http://support.microsoft.com/kb/238425/.
This is quite important, otherwise you'll experience your web app hanging and all sorts of strange nonsense going on.
Here are a few articles describing how to call a web service from a class ASP page:
Integrating ASP.NET XML Web Services with 'Classic' ASP Applications
Consuming XML Web Services in Classic ASP
Consuming a WSDL Webservice from ASP
A number of the answers presented here appear to cover how ClassicASP can be used to consume web-services & REST calls.
In my opinion a tidier solution may be for your ClassicASP to just serve data in REST formats. Let your browser-based client code handle the 'mashup' if possible. You should be able to do this without incorporating any other ASP components.
So, here's how I would mockup shiny new REST support in ClassicASP:
provide a single ASP web page that acts as a landing pad
The landing pad will handle two parameters: verb and URL, plus a set of form contents
Use some kind of switch block inspect the URL and direct the verb (and form contents) to a relevant handler
The handler will then process the verb (PUT/POST/GET/DELETE) together with the form contents, returning a success/failure code plus data as appropriate.
Your landing pad will inspect the success/failure code and return the respective HTTP status plus any returned data
You would benefit from a support class that decodes/encodes the form data from/to JSON, since that will ease your client-side implementation (and potentially streamline the volume of data passed). See the conversation here at Any good libraries for parsing JSON in Classic ASP?
Lastly, at the client-side, provide a method that takes a Verb, Url and data payload. In the short-term the method will collate the parameters and forward them to your landing pad. In the longer term (once you switch away from Classic ASP) your method can send the data to the 'real' url.
Good luck...
Another possible solution is to write a .NET DLL that makes the calls and returns the results (maybe wrap something like RESTSharp - give it a simple API customized to your needs). Then you register the DLL as a COM DLL and use it in your ASP code via the CreateObject method.
I've done this for things like creating signed JWTs and salting and hashing passwords. It works nicely (while you work like crazy to rewrite the ASP).
Another possibility is to use the WinHttp COM object Using the WinHttpRequest COM Object.
WinHttp was designed to be used from server code.
All you need is an HTTP client. In .Net, WebRequest works well. For classic ASP, you will need a specific component like this one.