Is there a way to develop a Component to interact with another platform's content ? Both are CQ based applications hosted on different servers.
In other words how to communicate between two platforms (both are CQ applications on different servers)
Cross domain interaction challenges are the same in CQ as in any web application. While several approaches exist, I've found JSONP to be the easiest option for allowing cross-domain communication. You could build a .jsonp selector (such as by adding a jsonp.jsp to your component) and make the JSP functionality very similar to the built-in .json selector that lets you see a node in the CRX repository in JSON format. In this case your selector would need to return JSONP format instead of JSON, and it would probably want to accept a callback name as an input parameter (such as ?callback=myCallbackname) so that it could wrap the JSON it returns in a function with the requested name.
Then, with that selector deployed on one CQ platform, you could construct a component on the other platform that would make JSONP AJAX requests to the other CQ platform using the .jsonp selector to fetch information. Really, the .jsonp selector can be coded to do whatever you want or need it to do, so if fetching node information is not exactly the sort of communication you need, it could do something else. As long as the AJAX jsonp request receives an appropriate JSONP response, you can communicate cross domain.
See What is JSONP all about? for more info on JSONP.
Also see http://api.jquery.com/jQuery.ajax/ for jQuery's JSONP support, as an example.
Related
I have developed an application which was MVC application. It has a requirement that the application will return json data for one get request.
So I have added apicontroller and created a get method to return json data.
So far so good. but then I thought, is it really needed to add apicontroller to create just one get method.
I started exploring and googling what is the difference other than content negotiation. Got lots of answers and articles but non of them were satisfactory.
So here is the actual confusion, why can't I just create a method in the MVC controller with JsonResponse and return the json data(Which I know only is need for my requirement, but other application on different domain will consume it).
Can anyone convince me why should I use apicontroller instead of MVC JsonResponse for my requirement or should I not be using apicontroller at all.
apology if there is any mistake.
If I get it right the question is Can we use MVC action to serve json content answer is yes! Is it okay to use Json Result? answer is It depends where do you want to consume it
Say I am an in a Web Environment where I have no need for the APIs (that means I am not going to serve my data to multiple clients) If that's the scenario where only your View is going to consume data returned from your Action Method you are good to go. An Action returning a Json Result is basically an Action Result and that's what it is made for.
but If you are in a REST scenario and you need your backend to serve your data to the client de facto standard is to use an independent Web API for that.
Controllers' main responsibility should be to work as an intermediary between your View and Model and whatever service layer you want to bring inside it. on the other hand, Web APIs are data-driven there only purpose is to serve data (use them if you need them)
Web APIs are good cause they give you the flexibility of serving the data to possibly any client that might need it. That's what I would pick if I am starting from scratch but if I only need to serve data to one client Controller Action methods will be way to go.
Hope this helps.
We have used Breeze in our solution and it is working well. However, we are now at a place where we need to pass some identifying information as part of the header when we make the WebAPI call. How is this accomplished with Breeze queries?
I assume this link should help you;
http://www.breezejs.com/documentation/controlling-ajax
In general, you need to configure the internal ajax adapter (probably jQuery) before making a request.
I read in an article that odata can be used for different combination of clients/servers.
Say I would like to develop a web application where i store data(say information about all mobile products on market) using mongoDB and use python as backend with Bottle framework to access data through browser as GET.
Then i decide to extend web app as android app. i can extend it to android without any code change on server side.
My doubt is does using odata here helps in any way? Say if i want to extend it to other clients?
Yes, you are right, you don't need to change even a single line of code on the server side if you change a client app. OData defines many conventions for the communications between the client and the server. such as:
What the URL looks like if you want to query some data
http://services.odata.org/V4/OData/OData.svc/Products?$filter=ID gt 2&$select=ID,Name,Rating,Price&$orderby=Price desc
Which http method should be used to Create/Retrieve/Update/Delete an entity
Generally speaking, Post for Create, Get for Retrieve, Patch/Put for Update, Delete for Delete.
What the payload looks like.
How to invoke a function/action
As long as the requests conform to these conventions, the server side always returns the predictable responsese regardless whether the clients is a browser or a mobile device.
I also find the examples for the odata:
https://aspnet.codeplex.com/SourceControl/latest#Samples/WebApi/OData/v4/ .
Hope this helps you.
So we're developing a web application in Symfony2 (brief editorial: Symfony2 is freaking awesome) along the lines of an SOA. All data is farted back and forth between our jQuery powered frontend and the Symfony2 backend formatted a la JSON, and therein lies the rub.
Symfony2 provides for a robust security system, but it seems to hinge on the "Security Layer" intercepting form submissions and using the form-encoded POST data to process an authentication attempt. This is problematic for our application because we use JSON exclusively. From where I'm standing, using JSON for every single request and response except authentication is... the sheet of the bool, frankly. Bad smell, bad juju, whatever you call it.
Now, Symfony2 allows for the creation of event listeners that hook into a series of events related to the lifecycle of a request and the consumate response. We use one of these hooks to decode the JSON that comes in with every POST request so that the relevant controller only ever has to worry about working directly with a php array and not do any decoding or de-serializing or whatever.
So the crux of our issue is that the "Security Layer" expects that form-encoded POST data that it gets from a form submission (generally on a page that the backend served in the first place). We're set up to feed it a PHP array created from JSONified data. So what do? Should we:
Create a custom authentication service that is built to deal with an array made from le JSON?
Tweak our request hook to check the target uri of each request and subsequently massage the request's JSON into the form-encoded string the "Security Layer" expects?
Tweak the "Security Layer" so that it can work the the JSON turned php array?
It's fairly simple to create your own authentication provider. You can follow this cookbook article and modify it slightly to handle your JSON request instead of the WSSE used in that example.
(I'm not familiar to RESTFul, please correct me if my concept is wrong)
In RESTFul architecture, we map every action to an URL. If I click "post a article", may it's actually URL http://example.com/ and some data action=post&content=blahblah.
If I want to post, but not refresh the whole web page, I can use javascript's XMLHTTPRequest. I post it and then get it's content and insert it to a div in my page. These action is all asynchronous.
Then I know there is something named WebSocket and it's wrapper socket.io. It use "message" to communicate between client and server. When I click "post" the client just call socket.send(data) and wait for server's client.send(data). It's magical. But how about URL?
It's possible to use the two model both without repeating myself? In other word, every action has it's URL, and some of them can interact with user real-timely(by socket.io?)
Moreover, should I do this? In a very interactive web program(ex. games), the RESTFul is still meaningful?
You're defining a handler for actions that map to REST over http. POST and GET generally refer to update and query over an entity. There's absolutely no reason you can't just define a handler for generic versions of these CRUD operations that can be used in both contexts. The way I generally do this is by introducing the concept of a 'route' to the real-time transport, and mapping those back to the same CRUD handlers.
You have a session, you can impose the same ACL, etc.
+---------------------------------+
| |
| BROWSER |
| |
+--+--^-------------------+---^---+
| | | |
| | | |
+--v--+---+ +--v---+---+
| | | |
| HTTP | | SOCKET.IO|
+--+---^--+ +--+---^---+
| | | |
+--v---+------------------v---+---+
| |
| ROUTING/PUBSUB |
+-+--^-------+--^-------+--^------+
| | | | | |
+-v--+--+ +-v--+--+ +-v--+-+
| | | | | |
| USERS | | ITEMS | |ETC |
+-------+ +-------+ +------+
ENTITY CRUD HANDLERS
I posted this on my blog recently:
Designing a CRUD API for WebSockets
When building Weld, we are using both REST and WebSockets (Socket.io). Three observations on WebSockets:
Since WebSockets are so free-form, you can name events how you want but it will eventually be impossible to debug.
WebSockets don’t have the request/response form of HTTP so sometimes it can be difficult to tell where an event is coming from, or going to.
It would be nice if the WebSockets could fit into the existing MVC structure in the app, preferably using the same controllers as the REST API.
My solution:
I have two routing files on my server: routes-rest.js and routes-sockets.js
My events look like this example: "AppServer/user/create".
I use forward slashes (“/”) to make the events look like routing paths.
The first string is the target (~”host name” if this actually was a path).
The second string is the model.
The third string is the CRUD verb: i.e. create, read, update, delete.