{"id":1806,"date":"2017-01-09T10:33:38","date_gmt":"2017-01-09T15:33:38","guid":{"rendered":"http:\/\/cs4760.csl.mtu.edu\/2017\/?page_id=1806"},"modified":"2017-03-03T10:16:03","modified_gmt":"2017-03-03T15:16:03","slug":"mashup-programming","status":"publish","type":"page","link":"http:\/\/cs4760.csl.mtu.edu\/2017\/lectures\/mashup-programming\/","title":{"rendered":"Mashup Programming"},"content":{"rendered":"

Introduction<\/span><\/h1>\n

Mashup and Use<\/span><\/h2>\n

Mashup or mashing-up is when a website makes requests to multiple services to provide content requested by a user. <\/span><\/p>\n

It is a relatively new technique that enables a website to leverage the services from other sites and data providers. Mashing-up can be used to customize a service, e.g. simplifying the interaction. It can also be used to enhance a service, e.g. adding additional features to a service.<\/span><\/p>\n

Request Flow<\/span><\/h2>\n

The typical request flow is that the user makes a request to the host website and the host website responses to the user’s request by making the multiple requests to remote services, and then packages the responses from the remote services into a map, and final passes the map to the view to respond to user’s request. <\/span><\/p>\n

In this request flow there are two types of requests and responses. There is the request made by the user to the host website and the requests made by the host website to remote services. Likewise there are two types of responses. The responses made by the remote services and the response made by the host website to the user. These requests and responses are distinct and illustrated below. <\/span><\/p>\n

 <\/p>\n

Request flow: \u00a0User -------->> Host website ------->> Remote service\r\nResponse flow: User <<-------- Host website <<-------\u00a0Remote service<\/pre>\n
For a simple request made by the user, e.g. clicking on a link, the request is encoded in the URL and Grails routes the request to a controller and its action. In a more complex case, e.g. clicking on a submit button, Grails packages the form data into the “request” object and sends it the the controller’s action.<\/span><\/p>\n
http:\/\/docs.grails.org\/latest\/ref\/Servlet%20API\/request.html<\/span><\/a><\/p>\n
In Grails, or any MVC framework, the request are routed and handled by the controller. The controller may need to access the domain or other services to fulfill the request. After accessing the services the controller responds to the requests by packaging the data into a map and sending the map to the view. To be consistent with this this design pattern, the controller’s action should make the request to the remote services and package the data, i.e. responses from the remote services are packaged into a map for the view. <\/span><\/p>\n
The request object in Grails is named in reference to the host website, meaning that it is a request made of the website. It is not the object to use for the website to make a request to remote a service. A different object must be used by the controller to make requests to remote services. Groovy calls this object HTTPBuilder.<\/span><\/p>\n
https:\/\/github.com\/jgritman\/httpbuilder\/wiki<\/span><\/a><\/p>\n
In other languages HTTPBulider is called CURL.<\/span><\/p>\n