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.
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 am learning Django Rest Framework and one of the things I have noticed is that Viewsets provide actions such as .list, .post instead of method handlers such as .get, .post which in turn are provided by Views. The documentation says that actions are more flexible than method handlers but I can't seem to find any reason for this. Could you please share some information on why does Viewsets use actions and not the method handlers?
request handlers like .get() and .post() are based on http request methods, while actions like .create() or .list() are from a functionality point of view. Suppose you have a view class that can return a single user's info by user id or return all users in sorted order. These two requests are all GET requests from the client side, but with different parameters and purposes. If you just want to use .get() handler in this case you will need to define two view functions and register the two urls in url config. Or you can use ViewSet class or generic view with mixins that has action functions .list() and .retrieve() to handle these requests, then using router class to set the url configs that follows the REST url standards.
GET and POST are the only HTTP methods to use when dealing with forms.
Django’s login form is returned using the POST method, in which the browser bundles up the form data, encodes it for transmission, sends it to the server, and then receives back its response.
GET, by contrast, bundles the submitted data into a string, and uses this to compose a URL. The URL contains the address where the data must be sent, as well as the data keys and values. You can see this in action if you do a search in the Django documentation, which will produce a URL of the form https://docs.djangoproject.com/search/?q=forms&release=1.
GET and POST are typically used for different purposes.
Any request that could be used to change the state of the system - for example, a request that makes changes in the database - should use POST. GET should be used only for requests that do not affect the state of the system.
GET would also be unsuitable for a password form, because the password would appear in the URL, and thus, also in browser history and server logs, all in plain text. Neither would it be suitable for large quantities of data, or for binary data, such as an image. A Web application that uses GET requests for admin forms is a security risk: it can be easy for an attacker to mimic a form’s request to gain access to sensitive parts of the system. POST, coupled with other protections like Django’s CSRF protection offers more control over access.
On the other hand, GET is suitable for things like a web search form, because the URLs that represent a GET request can easily be bookmarked, shared, or resubmitted.
As an alternative to Socket.io, there is SockJS (https://github.com/sockjs/sockjs-client), which seems to be better maintained and more stable than Socket.io.
This question is about the conceptual understanding the architecture of using SockJS with a web framework, say, for building a chat application
My current understanding is that you need the SockJS-client and a SocketJS server (in my case, I intend to use SockJS-Tornado (https://github.com/MrJoes/sockjs-tornado)) to be able to make websockets-style communication.
But how does SockJS (SockJS-client + SockJS-Tornado) tie together with a web framework that does the rest of the work (e.g. serving the page, writing/reading to/from db, etc). For instance, how would SockJS-Tornado component communicates with the web server of the framework? In particular, any direction of doing this with web2py (a python web framework) is highly appreciated.
You're right, for SockJS you need a sockjs-capable server and a in-browser javascript client library.
There are generally two integration patterns, let's say you want to use sockjs-tornado:
You may have all your site served from Tornado. With that, hook sockjs-tornado to some path, for example 'http://mysite.com/sockjs'. In this scenario both your website and sockjs will be served from mysite.com domain.
You may keep your site in whatever language/framework it's written and add sockjs-serveras another compontent, under a different domain, like. 'http://sockjs.mysite.com/sockjs'.
Additionally, you may use any variation of this - for example: have two servers internally but expose them as one domain by using a smart loadblancer (like haproxy).
If you're using web2py as a framework you could look a comet_messaging.py in gluon/contrib. It provides a function (comet_send) for getting messages from web2py app out to your websocket clients. It is based on tornado (w/o SockJS support) but the DistributeHandler can subclass a SockJS connection to provide fallback transport support. In this approach your clients send messages via typical GET or POST HTTP requests which are handled by web2py controllers (or other framework) and receive messages from the web2py controllers calling comet_messaging.comet_send() which sends a post request to the tornado instance which then blasts it out to its list of listeners.
The modified lines in comet_messaging look like (Notice open becomes on_open):
class DistributeHandler(sockjs.tornado.SockJSConnection):
def on_open(self, r):
group,token,name = [None, None, None]
self.group = group or 'default'
self.token = token or 'none'
self.name = name or 'anonymous'
and
urls=[
(r'/', PostHandler),
(r'/token', TokenHandler),
(r'/realtime', DistributeHandler)]
Notice I had to remove the regex group in the DistributeHandler URLSpec because sockJS-tornado was choking on it. Still trying to figure out how get parameters from the path to the on_open handler.
This provides a full answer on how to integrate SockJS into Django: https://stackoverflow.com/a/10950702/675065
Basically you need:
Tornado + SockJS-Tornado
Redis + Brukva
I use this configuration in my own project and it works pretty well.
Or: You try the autobahn way: http://autobahn.ws/ (i didn't try it out yet)
So, I implemented an API provider to be accessed by both web application and mobile applications.
Most likely this will not be a large scale project, but I want to maximize my learning experience and geek out where I can.
Anyway, from what I understand, it seems like it's better to put the API provider service and the actual website on separate domains to make scaling easier.
For example, twitter has the website twitter.com and api.twitter.com.
One immediate issue would be dealing with the cross-domain issue with AJAX.
From what I gather, there are 2 ways to implement cross-domain AJAX
JSONP: I heard about it, but don't know much beyond the name
Proxy Server: so, my website is build on top of ASP.NET MVC and I was thinking about creating a APIProxy controller to handle all cross-domain API requests.
That way, I would make an AJAX call via $.ajax(settings) and then pass in the website URL that corresponds to the APIProxy controller. The APIProxy controller would then make the appropriate POST server calls and process the JSON responses and return the response back to AJAX callback functions.
I heard about flXHR about I don't want to use Flash because devices like the iPad or any a lot of mobile browsers don't support Flash.
Anyway, I just wanted to ask what are some of the best practices in managing a website with the API provider on a separate domain or subdomain.
When you request some JSON, it returns an object or array. Script tags are not subject to the same-domain rule. So instead making an AJAX call, you would essentially do this:
<script src="Http://api.example.com?param1=something&etc"></script>
That would load the JSON, and it would execute as JavaScript.
...But a simple object or array "executing" by itself isn't very useful. So when you request the JSON, you also include the name of a callback function. If the provider sees that a callback was provided, instead of just returning JSON, it actually returns JavaScript: the JSON is passed to your function as an argument.
Then, when the script loads, your function (which you already defined) is called, and given the JSON to work with.
That's JSONP.
Bibliography
Newton, Aaron. "Request.JSONP." Clientcide. 7 Dec. 2009. Web. 28 Jan. 2011.
what is different between ajax and webservices. Anybody provide with some examples?
It's nonsensical to compare these things.
"Ajax" is a process that occurs in the browser. It is the act of calling some local server-side page, without refreshing the "main" viewing area, and then doing various things with that result (grabbing the data, making changes, changing the existing DOM (adding elements), whatever).
Webservices are a Serverside-thing that allows you to call methods, in your code, but have that call actually go to a remote machine. The call to the Webservice is generally also made server-side.
The term "Ajax" is generally used :
When the request is sent by a browser (client-side) to a server
When the transfered data is XML or JSON or HTML.
The word "webservice" is generally used :
When the request is sent by a server to another server, without a browser being involved
When the transfered data is SOAP -- at least when it's a SOAP webservice ^^ (Opposed to REST, for instance, which generally doesn't imply SOAP)
But I'd say that Ajax is basically some specific kind of webservice.
i think ajax and web services are kind of similar, here is why i think so.
as i understood it, in your app sometimes you will have to implement an "API" which has several useful functions. and it is those functions which are called "web services". these 'functions' acts in response to the http requests and "does" something with the data provided.
in ajax siimilar kind of work happens as well,just through javascript thats it.
so, to sum it all up, an API has 'web services' within it, and ajax behaves like 'web services'. in this manner, yes i think it is correct to call ajax and web services similar.