There was requiremnet to retrieve images from a Content Management System and render the content to a portlet deployed in Liferay.
The application was built on top of Spring MVC portlet and the Service calls from Portlet was REST API calls. So the REST WS API was made to return a byte[] of the content
To sent binary data in REST call [senting binary over REST WS may be questioned], you should encode using sun.misc.BASE64Encoder and on the receiving end you can use sun.misc.BASE64Decoder to decode the data.
The code looks like this
Service API
@RequestMapping(value = "/cms/image", method = RequestMethod.GET)
public void (ModelMap modelMap){
byte[] buff= getBytes(); // Return the byte[] of the image
String imgaeArray= new sun.misc.BASE64Encoder().encode(buff);
modelMap.addAttribute("result", imgaeArray);
}
At Portlet end;
@Autowired
RESTRepository repository;
@RequestMapping(params = "action=preview")
public String preview(Model model, RenderRequest renderRequest,RenderResponse renderResponse) {
Map <String, Object> paramMap = new HashMap<String, Object>();
Map <String, String> map = repository.get("/cms/image", Map.class,paramMap);
byte [] imgaeArray= new sun.misc.BASE64Decoder().decodeBuffer(map.get("result"));
}
If you don't know the content type, then you may need to return a DTO in the REST API instead of just encoded byte[] . DTO can have the properties to hold the byte[] and the content type.
Showing posts with label REST. Show all posts
Showing posts with label REST. Show all posts
REST - Building Better Systems
REpresentational State Transfer (REST) in short is a simple solution for invoking Web Services through URL's
REST defines a set of architectural principles to design Web services. The RESTful Web Services focus on the system's resources, including how resource states are addressed and transferred over HTTP by a wide range of clients written in different languages.
REST is now a predominant Web service design model. REST is much simpler that the SOAP- and WSDL-based interface design.
REST style of Web Service invokes HTTP methods explicitly. The basic CRUD (create, read, update, and delete) operations are mapped with HTTP methods POST,GET,PUT,DELETE respectively.
In bad designs there is a chance of using these HTTP methods for unintended purposes, For example;
GET /addemployee?name=Chris HTTP/1.1
addemployee is a state changing operation over HTTP method ,GET. If the above request is successful, it will an employee to the database.
HTTP Servers are designed to respond to GET method to retrieve information for the data store. So from the view of HTTP servers the above usage is wrong.
Similar to Create or operations like update ,delete can be invoked in a similar way, which will cause a state change in the server.
The other side of the problem is , this will cause sever side changes if the link is crawled even un intentionally.
To overcome this, the parameter name and values can be represented as XML tags and sent as a body of the HHTP POST request.
The receiver of this request will process this and add the resource in the body as a child of the resource identified in the request URI. In the above example the employee is the resource in the request URI, and Chris will be added under employee.
This is an example for RESTful service.
To update the name of an employee, the RESTful way of doing is to send a PUT request.
The key concept behind defining Restful interface is reusing the “verbs” defined the protocol. For example, employee, parts, machine all are nouns, think of what we can do with theses nouns, it could be get employee, get parts etc. “GET” is the common verb for all the nouns. GET is already defined in the protocol. The service should not define new verbs or remote procedures.
To be more clear, instead of defining services like getemployee, getpart use the universal verb , “GET” to define these services. POST for the services like addemployee, addpart etc. For Update use the PUT request.
The URL will define the resource on which the action needs to be taken ex, employee in the case of the URL, POST /employee HTTP/1.1
The other important design concept in REST is that the body part of HTTP request should carry only the state of the resource and not to carry any name of the remote method or remote procedure.
REST design reduces dependency with the application server than the SOAP- and WSDL-based kind.
REST defines a set of architectural principles to design Web services. The RESTful Web Services focus on the system's resources, including how resource states are addressed and transferred over HTTP by a wide range of clients written in different languages.
REST is now a predominant Web service design model. REST is much simpler that the SOAP- and WSDL-based interface design.
REST style of Web Service invokes HTTP methods explicitly. The basic CRUD (create, read, update, and delete) operations are mapped with HTTP methods POST,GET,PUT,DELETE respectively.
In bad designs there is a chance of using these HTTP methods for unintended purposes, For example;
GET /addemployee?name=Chris HTTP/1.1
addemployee is a state changing operation over HTTP method ,GET. If the above request is successful, it will an employee to the database.
HTTP Servers are designed to respond to GET method to retrieve information for the data store. So from the view of HTTP servers the above usage is wrong.
Similar to Create or operations like update ,delete can be invoked in a similar way, which will cause a state change in the server.
The other side of the problem is , this will cause sever side changes if the link is crawled even un intentionally.
To overcome this, the parameter name and values can be represented as XML tags and sent as a body of the HHTP POST request.
The receiver of this request will process this and add the resource in the body as a child of the resource identified in the request URI. In the above example the employee is the resource in the request URI, and Chris will be added under employee.
This is an example for RESTful service.
To update the name of an employee, the RESTful way of doing is to send a PUT request.
The key concept behind defining Restful interface is reusing the “verbs” defined the protocol. For example, employee, parts, machine all are nouns, think of what we can do with theses nouns, it could be get employee, get parts etc. “GET” is the common verb for all the nouns. GET is already defined in the protocol. The service should not define new verbs or remote procedures.
To be more clear, instead of defining services like getemployee, getpart use the universal verb , “GET” to define these services. POST for the services like addemployee, addpart etc. For Update use the PUT request.
The URL will define the resource on which the action needs to be taken ex, employee in the case of the URL, POST /employee HTTP/1.1
The other important design concept in REST is that the body part of HTTP request should carry only the state of the resource and not to carry any name of the remote method or remote procedure.
REST design reduces dependency with the application server than the SOAP- and WSDL-based kind.
Subscribe to:
Posts (Atom)