Expand my Community achievements bar.

SOLVED

Conclusion - Consuming REST API or Web Service from AEM

Avatar

Level 1
 
As far as i know, to the best of my knowledge a better implementation to consume a REST API or a Web Service API is to introduce a HTTPClient (Apache or Jersey Client or any Client). Very much like the post in 
 
There is always a better way to do it, If there are two ways to make a choice,
 
Approach 1. Make JavaScript Ajax Calls to consume the REST API or WebServices
Approach 2. Use a HttpClient on the OSGI Service Layer to consume these services and may be use a mapper like jackson ObjectMapper to convert the JSON response to a POJO
 
I need to understand and/or convince my client that the second approach is a better approach for obvious reasons.
 
There is always a better way to do it, but in this case to the best of my knowledge the second approach seems to be more robust, since we can have better control on the code, better error handling, ObjectMapper Conversions, etc …… and if javascript needs some data there can be a call to a SlingServlet to feed the data.
 
Which one would you prefer ? Can you comment on this post giving some reasons advantages and disadvantages in Approach 1 or Approach 2so i can support my case.  Your help is much appreciated. 

-skullblower

1 Accepted Solution

Avatar

Correct answer by
Level 10

Exactly -keep the code that invokes the 3rd party web service within an OSGi bundle (ie - a service, a servlet, or a custom workflow step). Make sure you follow this:

Never try to consume a 3rd party WS using JavaScript. Always use it via JAVA in an OSGi as discussed in the above articles. 

View solution in original post

6 Replies

Avatar

Level 10

It all depends on what 3rd party service you want to consume in AEM. If you want to consume a 3rd party SOAP Stack that exposes a WSDL - then create Java proxy classes and wrap those in an OSGi bundle as shown in 2nd article.   If you want to consume a 3rd party Restful service (ie - a Google Restful service  that uses Map functionality) then 1st approach is best to use. 

Avatar

Level 1

I agree to your point. let me give a scenario, 

Lets say, 

Just for an example sake (i cannot share the information so i am making up some thing here),

When I login to a banking application i have a some REST API calls which exposes information as Profile API, Account Balance API, Transactions API, Print My Statement API, Recent Transactions API, etc ....  there are about 15-20 REST API calls. (consider security is all implemented by some Oauth or SiteMinder etc..)

I might have to trigger some workflows, like when a check is deposited and it failed, i need to send out an email to a certain group with the check information so they can call the customer. Or sending an alert to a Payee about their recent email transaction.

which one should i prefer now ?

Avatar

Level 10

If you have Choice on what Web service technology to use to consume a 3rd party service and  pull in information into AEM, use Restful API. You can even build a custom AEM workflow step that does this. (That would make a good AEM article). So if you looking on what way to use in AEM (or from a workflow in AEM), I would use Restful. It's more lightweight than converting a 3rd party Soap stack into Java proxy classes.

However, if the 3rd party endpoint exposes a WSDL, then convert that WSDL into Java proxy classes. You could also use these Java proxy files in a custom workflow step.

Hope this helps.

Avatar

Level 10

Hi , points from this corner, 

As you have option to get the data from both client side and server side, I would have prefer server side. There could be many details you might want to keep with you. In real time you might not need all the detail all time. Pulling data from ajax might be a bad option if code is written badly and data is too much, it can affect client side performance ( which customer hates ). Again if user forget to logout, he / she can leave important data on browser mistakenly which is never a good option.

You can pull all data from secure server via rest API call, keep it on your server and make client call to your server when ever you need some data. Don't pull data you don't need. So I feel what you mentioned above, you can go for it. 

Avatar

Correct answer by
Level 10

Exactly -keep the code that invokes the 3rd party web service within an OSGi bundle (ie - a service, a servlet, or a custom workflow step). Make sure you follow this:

Never try to consume a 3rd party WS using JavaScript. Always use it via JAVA in an OSGi as discussed in the above articles. 

Avatar

Level 1

Perfecto. Thanks for your response scott and edubey. It makes perfect sense.