Given a SOAP service at a Uri http://www.example.com/index.php/api/v2_soap?wsdl=1 (Magento in this case)
How can I work out what URL is called when a particular method sales_order_invoice.list is invoked?
The reason for this question is that I need to be find out if the sites rewrite rules are interfering with the method call by rewriting the uri.
Is the uri one of:
http://www.example.com/index.php/api/v2_soap/sales_order_invoice.list
http://www.example.com/index.php/api/sales_order_invoice.list
http://www.example.com/index.php/sales_order_invoice.list
http://www.example.com/sales_order_invoice.list
Or something else entirely?
It's something else entirely. The API interface you're describing is a RESTful one. Different URLs for different resources. A SOAP API (Magento's or otherwise) doesn't work like that. All API requests go through
http://www.example.com/index.php/api/v2_soap?wsdl=1
The SOAP client will POST specifically formatted XML through the above endpoint URL, which will tell the the SOAP server which method needs to be called, and with what arguments.
Related
I have a SOAP endpoint which processes XML requests by identifying the unmarshalled object and then using appropriate handlers. Now, I am trying to make a new endpoint and handler method which would handle the same request differently. From what I understand, Spring-Webservices (or SOAP for that matter) doesn't have a RESTful-kind of routing for requests.
Can I route a SOAP request through two different endpoints with a URL suffix or something in the API path (kind-of RESTful) ? The namespace, localpart, etc all being same. If not, is there a way ?
SO doesn't seem to have working answers on this topic, tried this:
How can i have two separate web services with identical name space and local name requests be routed to different end points?
Multiple SOAP endpoints with one namespace & localpart
Any approach/ideas are appreciated.
As far as I understood, you need to execute different business logic methods depending on the flag value. Well, the most straightforward approach is to use an if statement directly inside the endpoint. If you want to call different API (controllers) methods, you can take a look at Spring Functional Endpoints. Though I'm not sure they are integrated with SOAP
The mentioned approaches in the question didn't work for me, so I used a mixed approach - made a RESTful api for the new endpoint with a different suffix in the url. I read the payload as a string and used marshallers to validate.
I have a general REST API (developed using Spring MVC) that takes a list of API requests as its request body.
Each API request in the list has its own URL and request body.
In the implementation of this general REST API, I need to call the corresponding Spring controller method (in the same app) for each of these individual API requests (with their appropriate URL and request body).
(I will then merge all those individual API responses and return it in one big response from the general REST API).
I've been searching around, but I'm unclear how to programmatically call Spring to execute each individual API request. I would ideally like to get back the ResponseEntity from each call instead of the actual JSON response.
(More information:
On the same app server as the general API, I need to translate the URL and JSON request body for each individual API into the arguments to the controller method. I also need to take the URL and have Spring determine which controller method to invoke itself.)
Any help would be greatly appreciated.
Thanks,
Matt
Answer depend on whether the individual URLs that you are planning to invoke is with in the same server (Accessible without using network call) or not
If it is with in the same app server, spawn multiple threads and invoke the individual methods and join the response together and send it back
If it is not within the same app server, there are many Async Restclients are there besides spring's own webclient/restTemplate etc
I am designing a Restful web service for an internal corporate application, and am curious how to merge JSON and "web content" requests.
The web application, like all good corporate applications, has a three-letter abbreviation that is reflected in the URL. Let's say that this application's "call sign" is abc, and the users access it at the following URL
http://servername/abc
When the users access the root of the application we want to serve them up the main html page, the .js files (including jquery), the css, and the images. Then, jquery will start to make AJAX calls back to the server.
What is the best way to handle these multiple content types?
http://servername/abc (returns contents of index.html)
http://servername/abc/javascript/jquery.js (returns a js file)
http://servername/abc/countries/de (returns JSON)
Should I split this into two web contexts? Should I use the jquery contentType parameter in the ajax calls to explicitly specify JSON versus HTML versus something else?
the jQuery contentType is really just a parameter that sets your content-type header on your HTTP request to the server. It is always a best practice to set these for your AJAX calls.
Added:
Another good practice is to specifiy the dataType parameter as that will set the accept header on your HTTP request. This is useful for both GET and POST AJAX requests.
Most, if not all, web service frameworks (Rails, ASP.NET MVC, .NET WCF, etc..) have abilities to examine the headers of an HTTP request and determine what type of content to serve back
for example:
application/json in an HTTP Header would let your webservice know to return a JSON response instead of an HTML or XML response.
Some of the better ways that I have seen web apps organized for HTML/JSON serving is to make your standard routes always serve your HTML pages and resources, ie:
http://servername/abc
http://servername/abc/javascript/jquery.js
would do exactly as you have said. For your JSON (or even XML) responses, I see folks create a route that is explicity understood to serve back those types of responses, ie:
http://servername/api/abc/countries/de
the url route begins with an /api/ which would always be understood to serve back a non-html JSON/XML response
this makes it pretty easy for your company to internally and externally understand that /api/ routes are your JSON/XML responses. It also makes it easier to expose these methods to your customers externally should you want to do that as the infrastructure is there, you would just need to authenticate, etc... the requests.
A good way to do this is to use the standard HTTP Accept Header. In your ajax requests, you would specify this header to be application/json, and then all other web requests would include the browser's accept headers. Then, on the server side, you could use the Accept header to determine which content to serve.
If you use JQuery, then the Accept header will be set to application/json automatically if your dataType parameter is set to "json."
In my application there is a client and a WCf REST service. For invoking some wcf service the client is doing an http POST even though the service is a GET.
i do not want to do any changes in the client or the service.
So is there a way where i can convert this POST request to GET and add the data coming in as the POST to the URL and invoke the REST service.
Thanks in advance.
You can use URL Rewrite to issue 3xx Redirect which will use GET method, but you will loose all POST data.
The only safe way known to me is to rewrite POST request to some another custom page, where you:
collect all POST data/variables;
convert them into GET variables (assemble proper GET request);
issue 301 (or 302) Redirect to the proper URL (it will have all POST data sent as GET variables).
Such rewrite to custom page should be easy -- you need to check what method is used (POST or GET) and only invoke it on POST. The rest will be handled in that post-to-get script.
The reason for all of this complexity is the difference in how POST and GET requests work: with GET all data is sent as part of URL while POST uses request body to transfer variable's data.
In every MVC framework I've tried (Rails, Merb, Waves, Spring, and Struts), the idea of a Request (and Response) is tied to the HTTP notion of a Request. That is, even if there is an AbstractRequest that is a superclass of Request, the AbstractRequest has things like headers, request method (GET, POST, etc.), and all of the other things tied to HTTP.
I'd like to support a request-response cycle over SMS, Twitter, email, or any other medium for which I can make an adapter. Is there a framework that does this particularly well?
The only other option I've thought of is creating, for example, a Twitter poller that runs in a separate thread and translates messages into local HTTP requests, then sends the responses back out.
If there were a good framework for multiple request media, what would routing look like? In Rails, the HTTP routing looks something like:
map.connect 'some/path/with/:parameter_1/:paramter_2', :controller => 'foo', :action => 'bar'
How would a Twitter or SMS route look? Regular expressions to match keywords and parameters?
I haven't seen one. The issue is that the request is also tied to the host, and the response is tied to the request.
So if you get a request in via email, and a controller says to render view "aboutus", you'd need the MVC framework to know how to :
get the request in the first place - the MVC framework would almost need to be a host (IIS doesn't get notified on new emails, so how does your email polling code get fired?)
allow flexible route matching - matching by path/url wouldn't work for all, so request-specific controller routing would be needed
use the aboutus email view rather than the SMS or HTTP view named "aboutus"
send the response out via email, to the correct recipient
A web MVC framework isn't going to cut it - you'll need a MVC "host" that can handle activation through web, sms, email, whatever.
The Java Servlet specification was designed for Servlets to be protocol neutral, and to be extended in a protocol-specific way - HttpServlet being a protocol-specific Servlet extension. I always imagined that Sun, or other third poarty framework providers, would come up with other protocol-specific extensions like FtpServlet or MailServlet, or in this case SmsServlet and TwitterServlet.
Instead what has happened is that people either completely bypassed the Servlet framework, or have built their protocols on top of HTTP.
Of course, if you want to implement a protocol-specific extension for your required protocols, you would have to develop the whole stack - request object, response object, a mechanism of identifying sessions (for example using the MSISDN in an SMS instead of cookies), a templating and rendering framework (equivalent of JSP) - and then build an MVC framework on top of it.
You seem to be working mostly with Java and/or Ruby, so forgive me that this answer is based on Perl :-).
I'm very fond of the Catalyst MVC Framework (http://www.catalystframework.org/). It delegates the actual mapping of requests (in the general, generic sense) to code via engines. Granted, all the engine classes are currently based on HTTP, but I have toyed with the idea of trying to write an engine class that wasn't based on HTTP (or was perhaps tied to something like Twitter, but was separated from the HTTP interactions that Twitter uses). At the very least, I'm convinced it can be done, even if I haven't gotten around to trying it yet.
You could implement a REST-based Adapter over your website, which replaces the templates and redirects according to the input parameters.
All requestes coming in on api.yourhost.com will be handled by the REST based adapter.
This adapter would allow to call your website programmatically and have the result in a parseable format.
Practically this means: It replaces the Templates with an own Template Engine, on which this things happen:
instead of the assigned template, a generic xml/json template is called, which just outputs a xml that contains all template vars
then you can make your Twitter Poller, SMS Gateway or even call it from Javascript.