ServiceBuilder without real entities

[Vinicius Vargas, geändert vor 7 Jahren.]

We are starting a new Liferay project, and it's the first time we use this platform here. One of our issues is that we need to expose a webservice built with ServiceBuilder without a database entity. All our data will be fetch from an external server and will be routed to our clients through Liferay WebServices, so in this case, we don't necessarily need to have a local database to store this kind of data. Just to be clear, I'm talking about REST services here.

So, I have two questions:
-How can I create REST services with Liferay from the ground up, without needing to create a database entity for it?
-If this is not possible, how can I integrate Liferay's Authentication and Authorization with another webservices framework (like jax-rs or spring mvc for instance)?

[Pavel Savinov, geändert vor 7 Jahren.]

Hey Vinicius,

Take a look on this blogs entry:
https://web.liferay.com/web/vitor.silva/blog/-/blogs/using-restful-services-with-liferay

It explains how to integrate Liferay(including auth and permissions) with Spring RESTFul web services.

[Vinicius Vargas, geändert vor 7 Jahren.]

Hey Pavel, thank you for the quick answer.

Right now I'm inclined to use ServiceBuilder, mostly because it can integrate seamlessly with the Mobile SDK to generate Android/iOS libs to consume our services. Do you know how to create those services without creating a database entity?

[Pavel Savinov, geändert vor 7 Jahren.]

Sure, you are still able to create an entity without it's database representation, like this:
https://web.liferay.com/web/user.26526/blog/-/blogs/fake-servicebuilder-entities

[Vinicius Vargas, geändert vor 7 Jahren.]

We tried to use fake entities, but this way we will create entities that we would never use in our App. I want to expose services without entities, and leveraging to ourselves the creation of our request/response objects (POJOs).

[Pavel Savinov, geändert vor 7 Jahren.]

Well, I still don't get it, why don't you want to use fake entities?

ServiceBuilder generates some classes, you just have to put there all you need, for example, in FakeEntityServiceImpl you can put:

    @Override
	public POJO getMyCustomPojo() {
		return new POJO();
	}

Generate your service with ServiceBuilder, deploy it and use it like this:

JS example:

Liferay.Service(
  '/fake.fakeentity/get-my-custom-pojo',
  function(obj) {
    console.log(obj);
  }
);

curl example:

curl http://localhost:8080/api/jsonws/fake.fakeentity/get-my-custom-pojo -u [e-mail]:test

It makes you able to use any Liferay stuff in your service implementation, but at the same time return anything you like...

Or you want something else?

[Vinicius Vargas, geändert vor 7 Jahren.]

The problem with fake entities, is that ServiceBuilder will generate classes that I will never use. For example, if I create a fake entity Foo, there will be some Model and Persistence classes derived from Foo that I will NEVER use in our project.

What I want: create a MyServiceImpl class, that can be exposed without an entity class. Is there any way of achieving it in Liferay?

[Jack Bakker, geändert vor 7 Jahren.]

Vinicius Vargas:

The problem with fake entities, is that ServiceBuilder will generate classes that I will never use. For example, if I create a fake entity Foo, there will be some Model and Persistence classes derived from Foo that I will NEVER use in our project.

So don't use the additional generated classes [edited for more clarity]. I find service builder really useful in general, and then the fake entity trick adds a useful feature that service builder was not designed for in the first place. How cool is that ?

[David H Nebinger, geändert vor 7 Jahren.]

Vinicius Vargas:

The problem with fake entities, is that ServiceBuilder will generate classes that I will never use. For example, if I create a fake entity Foo, there will be some Model and Persistence classes derived from Foo that I will NEVER use in our project.

Seriously? Have you ever looked at all of the classes in the JDK? Would you discard java because it has a lot of extra stuff in there?

This argument just doesn't make any sense. You can create a fake entity, build a complete infrastructure around it, expose it as a JSON web service, all with a small bit of XML for the entity and a command-line call to build the services.

But because it generates classes you won't use, you're going to discard it all and hand-craft some untested solution that will require all of the development and maintenance to fall on your shoulders.

Nonsense. What's worse, when you leave there and they bring in a real Liferay consultant, they're going to gut your hand-crafted implementation and rebuild it using common liferay tools and practices.

[Vinicius Vargas, geändert vor 7 Jahren.]

I won't even try to debate about the comparison between the JDK and the classes of my own projects, that was a unfortunate example. I was asking about a possibility with the Service Builder, but it's clear now that I can't just expose a REST service the way I used to with JAX-RS or Spring MVC.

Please, close the topic. I have no further questions for now.

[David H Nebinger, geändert vor 7 Jahren.]

Okay, so JDK might not be an example you like, but how about Spring MVC or Hibernate or any other large project? There will always be classes that you may not directly or indirectly use.

While you might not use the service builder generated classes, they certainly don't hurt having them in there, they won't cause any problem, and you still get the benefit of an integrated, portal-friendly solution for non-db entities exposed via JSON web services.

There are definite arguments against SB solutions, but extra generated classes that aren't used really is not a valid one.

[Jack Bakker, geändert vor 7 Jahren.]

David, unless I am mistaken, I don't think Vinicius indicated he would never use Service Builder simply because additional files per entity are generated that wouldn't get used with the fake entity approach.

[David H Nebinger, geändert vor 7 Jahren.]

That is his quote from my post on the 28th...