RE: How to return JSON and HTTP status code together in remote service meth

thumbnail
ali yeganeh, modified 5 Years ago. Regular Member Posts: 148 Join Date: 5/1/19 Recent Posts
Hi

I implement my application’s remote service methods in *ServiceImpl .
How to return JSON and HTTP status code together?
thumbnail
Christoph Rabel, modified 5 Years ago. Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
I might be wrong here and the behavior was changed, but AFAIK, those API calls *always* return a HTTP 200 OK status code. We dont't use them anymore, but we always returned the real status code as part of the message and handled it in the success callback.
We only use the rest api anymore, we found it to be far more flexible than implementing the ServiceImpl methods.
thumbnail
ali yeganeh, modified 5 Years ago. Regular Member Posts: 148 Join Date: 5/1/19 Recent Posts
Hi Christoph Rabel
Do you have a sample code that I can return JSON and HTTP status code together  (look like JAX-RS api ) ?
javax.ws.rs.core.Response.status( Response.Status.OK ).entity( myEntity );
Thank you for your reply.
thumbnail
Andrew Jardine, modified 5 Years ago. Liferay Legend Posts: 2416 Join Date: 12/22/10 Recent Posts
Are you trying to use one of the out of the box JSONWS services that Liferay provides? or are you working with one that you have generated?
thumbnail
ali yeganeh, modified 5 Years ago. Regular Member Posts: 148 Join Date: 5/1/19 Recent Posts
Andrew Jardine:

Are you trying to use one of the out of the box JSONWS services that Liferay provides? or are you working with one that you have generated?
Hi
I produced it myself through the service builder .
Now, I want in my class ( *ServiceImpl ), return JSON and HTTP status code together?
thumbnail
Andrew Jardine, modified 5 Years ago. Liferay Legend Posts: 2416 Join Date: 12/22/10 Recent Posts
Ok I get it. The problem is that the methods want to return your entity. So all I can think of is, in your serviceImpl add a method that returns a JSONObject. In that custom method you define you can then, internally, call your service that returns your entity. Once you have the entity you can wrap it in a JSONObject that has an attribute with the status and an attribute with your entity. 

At the end of the day though, as Christoph has said, the response code is in the response headers anyway sooooo personally I think you should just use that.
thumbnail
Christoph Rabel, modified 5 Years ago. Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
With the generated services under /api/jsonws, I believe, you can't.
With the "general" rest services, you can create using the module template "Rest", you can do exactly as you wrote in your line.
https://help.liferay.com/hc/en-us/articles/360018166411-JAX-RS-
@GET
  public Response appHomepage(@Context User user, @Context HttpServletRequest request) {
      Something result;
      ...
     return Response.status(200).entity(result).build();
    } catch (AccessDeniedException e) {
      return Response.status(403).build();
    } catch (Exception e) {
      LOGGER.error(e);
      return Response.status(500).build();
    }
  }
I have come to vastly prefer the Whiteboard webservices to the /api/jsonws webservices. They were fine, if I had a fitting entity, but awkward otherwise.
thumbnail
Andrew Jardine, modified 5 Years ago. Liferay Legend Posts: 2416 Join Date: 12/22/10 Recent Posts
I'm with you on this one Christoph, the Whiteboard stuff is awesome and I have recently being playing around a lot with the Headless capabilities as well. 

For the JSON services, I've never actually tried it myself, but I am wondering if you could create a wrapper. For example, if you wanted to change the return found in the UserService, then you could define a UserServiceWrapper implementation with the overrides for the methods where you wanted to change the response structure. But now that I am looking at the code, that wouldn't work because the return type needs to be specific.  Something in the


com.liferay.portal.jsonwebservice
might be overridable if it is registered as an OSGI service, but honestly I think the easiest thing to do would be as you are suggesting. Just make your own REST service and minimize the amount of "customization". If nothing else, that will always make your upgrade paths less painful!