Expand my Community achievements bar.

SOLVED

Search Results

Avatar

Level 7

Hi,

In my project, there is a requirement to call a web service with some parameters, receive search results and display them in AEM.

Which components shall I use for the search results? Table component or something else?

Could you please direct me to sample code for populating a Table component or some grid component with search results programmatically?

Appreciate your help.

Thanks,

Rama.

1 Accepted Solution

Avatar

Correct answer by
Level 10

you can create table or grid component based on your application design. However you can refer [1] to get an idea of how to loop through the results and display the data in the grid 

[1] https://helpx.adobe.com/experience-manager/using/using-ajax-requests-display-cq.html

View solution in original post

5 Replies

Avatar

Correct answer by
Level 10

you can create table or grid component based on your application design. However you can refer [1] to get an idea of how to loop through the results and display the data in the grid 

[1] https://helpx.adobe.com/experience-manager/using/using-ajax-requests-display-cq.html

Avatar

Level 10

If you are using web service - be sure to build an OSGi service that invokes a 3rd party web service as discussed here: 

https://helpx.adobe.com/experience-manager/using/creating-cxf-bundles-consume-web.html

If you mean restful web service - check out this article:

https://helpx.adobe.com/experience-manager/using/restful-services.html

As Lokesh suggests - see that article for an idea on how to display the returned data into a table/grid component. 

Avatar

Level 7

Hi all,

Thanks for responding to my query.

These responses have been really helpful to me.

As a side note, I looked at the following URL for SOAP vs REST Web Services.

http://www.javatpoint.com/soap-vs-rest-web-services

But from consuming the web services from AEM perspectve, what are the differences?

I am aware that WSDL is one main difference.

I also acknowledge that it is not purely an AEM topic and that is why if someone could throw some light on it from AEM perspective, it helps me.

Appreciate your responses.

Thanks,

Rama.

Avatar

Administrator

Hi

First to answer the original question, AEM can be integrated with third party Applications using REST APIs or WebServices.

So we can call third party APIs with GET/POST actions with some parameters.

As mentioned by Scott, we can use following links for the same:-

Link:- https://helpx.adobe.com/experience-manager/using/creating-cxf-bundles-consume-web.html //Web Service

Link:- https://helpx.adobe.com/experience-manager/using/restful-services.html //Rest

 

No to answer you question on what is difference between SOAP and REST, please find below some explanations for it:

 REST

when you are exposing a public API over the internet to handle CRUD operations on data. REST is focused on accessing named resources through a single consistent interface.

SOAP
SOAP brings it’s own protocol and focuses on exposing pieces of application logic (not data) as services. SOAP exposes operations. SOAP is focused on accessing named operations, each implement some business logic through different interfaces.

 

SOAP and REST can't be compared directly, since the first is a protocol (or at least tries to be) and the second is an architectural style. This is probably one of the sources of confusion around it, since people tend to call REST any HTTP API that isn't SOAP.

Pushing things a little and trying to establish a comparison, the main difference between SOAP and REST is the degree of coupling between client and server implementations. A SOAP client works like a custom desktop application, tightly coupled to the server. There's a rigid contract between client and server, and everything is expected to break if either side changes anything. You need constant updates following any change.

A REST client is more like a browser. It's a generic client that knows how to use a protocol and standardized methods, and an application has to fit inside that. You don't violate the protocol standards by creating extra methods, you leverage on the standard methods and create the actions with them on your media type. If done right, there's less coupling, and changes can be dealt with more gracefully. A client is supposed to enter a REST service with zero knowledge of the API, except for the entry point and the media type. In SOAP, the client needs previous knowledge on everything he will be using, or it won't even begin the interaction. Additionally, a REST client can be extended by code-on-demand supplied by the server itself, the classical example being javascript code used to drive the interaction with another service on the client-side.

To understand what REST is about, and how it differs from SOAP:

  • REST is protocol independent. It's not coupled to HTTP. Pretty much like you can follow an ftp link on a website, a REST application can use any protocol for which there is an standardized URI scheme

  • REST is as standardized as the parts you're using. Security and authentication in HTTP is standardized, so that's what you use when doing REST over HTTP.

 

Some Reference Links:- http://spf13.com/post/soap-vs-rest

I hope this would help you.

Thanks and Regards

Kautuk Sahni



Kautuk Sahni

Avatar

Level 7

That helps a lot.

Appreciate the long and informative note.

Thanks,

Rama.