I've created an Adobe aem bundle. I want to expose it as a restful web-service.How can I do it. I see there are explanation for consuming a third-party rest service but not enough information as to how to expose your own AEM bundle as a rest service.
Exposing a proper REST API is quite a challenge of its own. I'm not going to dwell on it here because there's a lot of excellent material on the web. Just google for REST and HATEOAS. The book RESTful Web APIs by Leonard Richardson and Michael Amundsen also describes the subject very nicely.
That said, I'm not sure what you mean about exposing an AEM bundle as a REST service but it's probably going to take quite a lot of design work.
An OSGi bundle (I assume that's what you meant by AEM bundle (sic!) ) can potentially expose a number of OSGi services, each with a separate set of available methods.
While you could technically draw a parallel between an OSGi service (with its own API that's basically a set of Java methods to be called by other components in the OSGi environment) and a RESTful web service (with its hypermedia-driven API available over HTTP), the design constraints for both types of services are completely different. You can't just expose an OSGi service using a RESTful web service.
What you need to do is to design a RESTful Web API and back it up with the OSGi bundle that you have.
One way this could be done is by creating a number of Sling Servlets. These servlets are themselves OSGi components and, therefore, can ingest OSGi services that your bundle already exposes.
I have no way of knowing what your API is supposed to do but if it's about storing data in the Content Repository, you should keep in mind that Sling itself is built around the principles of REST. What you want to achieve may well be doable using the OOTB servlets and appropriately composed forms (hypermedia controls).
As AEM is built on top of REST architectural concept it exposes Restful endpoints via Servlets. You can use the default SlingServlets like GET/POST methods or write your own Servlets by extending the SlingAllMethodsServlet (i.e. Sling Servlet that accepts GETs or POSTs)
Other clients that are able to perform REST requests can sent REST requests to your AEM (calling your AEM Servlet) by performing GET or POSTs.
For an example JSON representation of the OOTB content by using the default sling GET Servlet can be seen by below urls which renders you the content in JSON format with child levels(depth content) based on the selector
http://localhost:4502/cf#/content/geometrixx-outdoors/en/men/coats.json
http://localhost:4502/content/geometrixx-outdoors/en/men/coats.1.json
from the client end there are multiple ways of calling these Servlets like by AJAX, JAVA SWING applications, HTTP FORM Post, etc,.
Some examples are shown in below articles.
AJAX CALL TO SERVLET, USING .net call to AEM, Using AEM POST CALL
~Hope it helps
if you create a class in you core project under servlets package, you can define a restful service using annotation:
#SlingServlet(paths = "/bin/pagesutils/importservlet", methods = "POST")
declaring also the method and the path.
Remember to allow the path of the servlet in your dispatcher configuration.
Related
I am currently reworking a legacy JAVA data driven web application to a MVC model. While reworking, I realized that almost all servlets call a getID() method and almost 10 other methods. I am thinking of converting these method calls to a service. This would be my first web service development. I use Eclipse and weblogic. While I am reading up online, can someone give me a brief outline of how this can be achieved to get a head start? Another question is, do these services get invoked from a business class or a servlet or a jsp or from all of these? Thanks.
Web service can mean XML-RCP, SOAP, or REST. To me, web service means "calling a networked component via HTTP." If you agree, you can simply refactor those methods into another servlet and call it a service.
Don't use XML request/response unless you need to.
I would not invoke services from business classes. Servlets and JSPs are firmly in the web tier, so I can both calling a web service (e.g. AJAX calls from a page).
But my preference would be to have a true service layer, with services calling services. The service layer is more reusable than it'll be if you embed that stuff in the web tier. What happens to all that code if you go with a mobile UI? The web tier should validate and bind input parameters, call services to fulfill the use case, and package up the response for display. Let the services do the heavy lifting.
I am new to Spring MVC3 framework in java but I am familiar with java coding.
I want to write two application using this framework.
First application recieves requests through a SOAP web services and sends response in form of SOAP XML Object.
Second application have a simple servlet to recieve request and send responces.
I have studied Java MVC3 framework. It requires view to be called who are mapped against which controller will handles its request. But,
How I can do this using a webservice, so that when a specific method using SOAP services is called, I can forward that request to its relevant servlet and sends response back as a SOAP xml file.
How can I do this for my second application as well that recieves request through a servlet.
I hope all this make sense.
regards,
Aqif
If you want to stick with Spring, you can use Spring Web Services for application 1. Application 2 would be a more traditonal Spring Web app (uses a servlet, but framework does not require you to work in the servlet...instead you will work in more fine grained components).
If you dont want to stick with Spring for the web services, you can always use something like Apache Axis
The usual structure is as follows:
you have spring-mvc controllers to handle your browser requests
you have other components that handle the SOAP requests
both of the above invoke the same underlying services which serve them with the data that is to be sent to the user. The data is in java objects, which are later transformed to whatever is required
For the 2nd point you can pick some JAX-WS implementation, like CXF (it has nice spring support as well)
Spring Web Services specifically supports a Spring MVC-like model for responding to SOAP calls, as you describe.
the second one is Spring MVC directly. Heck, it sounds like - though I can't be sure without more information - that you're trying to build RESTful web services. There, too, Spring MVC is the right choice.
Evening all :)
I'm looking to create a Java web application. I envisage that it will use Spring web MVC and JSPs, however I would like to expose certain functionality as REST calls so I can create an android client.
Does spring offer anything to help me in this area? How can I keep the REST code and the web front end code separate yet not have to maintain essentially 2 versions of my application (one for the web, one for REST clients).
Not looking for spoon feeding, just some pointers of where I should start reading.
As others have mentioned, Spring has pretty good in-built REST support now. When combined with annotations, this allows really simple set-up of a RESTful API. Spring can be configured with different view resolvers, which can automatically respond with a different view of the data depending on the Accept header for example. So you could return either JSON or JSP automatically from the same data, see the ContentNegotiatingViewResolver. Your Controller and Model can then be common and implemented once, leaving the work in the View layer.
I've used this approach before to return JSON when the request was via AJAX and a JSP view built with the same data when accessed by a browser.
Jersey is a pretty nifty tool. It integrates well with tools like Spring, Guice, and Jackson to provide you a pretty seamless way to create RESTful resources.
Jersey is pretty simple, works well, and serves as the reference implementation to boot. Plus, it has some nice REST client support, much of which will probably make it into the JAX-RS spec.
In terms of marrying that with Spring MVC, I'd recommend you make sure you model your application so that you have facades (Service classes) that provide all the core functionality you need and then simply reference them as needed in your MVC code or REST code. You shouldn't be duplicating business logic
You can do this using Spring 3.0. Spring 3.0 came out with the ability to specify #PathVariables to pull values out of the URL path (previously this was not easy in Spring MVC).
You would also use #RequestMapping to specify the HTTP method(s) each method in your controller should respond to.
I've also use Spring Security to implement an API key type of functionality. This way you can restrict access to your API in a way that is easy for REST clients to implement. I had to extend org.springframework.web.filter.GenericFilterBean and add a the proper Authentication like this
SecurityContextHolder.getContext().setAuthentication(apiKeyAuth)
There's a new REST API in Spring 3.0 MVC:
http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
http://www.springsource.org/download
Apache CXF integrates well with Spring and offers many method for exposing services. From the overview section of the CXF homepage:
CXF helps you build and develop
services using frontend programming
APIs, like JAX-WS and JAX-RS. These
services can speak a variety of
protocols such as SOAP, XML/HTTP,
RESTful HTTP, or CORBA and work over a
variety of transports such as HTTP,
JMS or JBI.
I have a Web Service accessible via SOAP. Let's assume it provides a method with the signature
sayHello(String name)
Of course, I have the WSDL describing the Web Service.
What I want to do now is to generate a client web application (war archive) with a GUI that provides a form to enter the parameter for the Web Service method. In case of the example, the form must just allow to enter the value for the "name" parameter. Then, a SOAP message must be assembled and sent to the WS.
Is there any way or any framework to generate such a webapp automatically!? The actual kind of the resulting webapp is not important, it may be a GWT webapp, JSF, plain Servlet with JSP or whatever. Even a plain HTML/JavaScript client app would be OK.
I mean, there are tools to generate CRUD forms out of data models, so there must be tools to create forms for Web Services, too...
I've been googling around for a long time, but the only thing I've found is a feature of Eclipse: http://www.eclipse.org/webtools/jst/components/ws/M3/tutorials/WebServiceClient.html . Basically, this does what I want, but I'm looking for a more ..hm.. elegant way to do this ;-)
Thanks in advance,
Frank
What you are looking for is (I think) similar to what this site seems to do: link soaptest
As far as I know there is no framework that supports this out of the box.
All frameworks support the automatic generation of client stubs and artifacts and application developers use that to implement their functionality.
In your case create the HTML interface your self to test the web service.
Only .NET web services provide similar tool for testing link text
If I remember correctly, Netbeans provides simple web pages to test the functionality of web services methods (methods offered by the server). You can find a decent amount of guides showing you how to create wevservice clients on youtube. It is a relatively straight forward process.
If it is just for testing the web service: go for soapUI. It's a standalone application and (to my opinion) a must for every SOAP engineer.
Basically I need webservice where client can request with id one boolean value from our webservice. What technology would be most suitable for this small API? Of course it is possible that there will be more functions to interface, but now we need only one function. It also needs to have authentication, so that only auhtorized clients can access service. And every client have different auth credientials.
What would be good technology for this purpose?
I am using resteasy to build my webservices and it is pretty easy to use ... just need to use annotations on my methods to deliver the webservices.
Here is a comparison of different JAX-RS frameworks. Take a look at it
First of all: authentication and authorization. Don't do it yourself, pick an app server or servlet container and configure it to do the job.
For the web service....
The simplest thing to do it just implement a servlet that responds to a POST (not a GET if request modifies internal state) and returns the result in the body. This way you don't need any frames works, no learning to do (if you already know servlets). The downside is it won't scale as you add more features, and your not using enough buzz words.
If you want a SOAP based webservice, then look at JAX-WS. Now that it's backed into java 6 it's pretty easy.
At the simplest level JAX-WS lets you put a few annotations on your class, like #WebService, and it auto generates a wsdl and exposes an instance of your class via the web service.
There is plenty of documenation out around how to do it:
http://java.sun.com/webservices/docs/2.0/tutorial/doc/
http://www.java-tips.org/java-ee-tips/java-api-for-xml-web-services/developing-web-services-using-j.html
http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
JAX-WS + any servlet container (Tomcat is usual choice)
#WebService(targetNamespace = "http://affinity.foo.com", name="RewardsStatus")
#SOAPBinding(style=SOAPBinding.Style.RPC, use=SOAPBinding.Use.LITERAL)
public interface RewardsStatusIF {
#WebMethod(operationName="GetLastNotificationDate", action="urn:GetLastNotificationDate")
#WebResult(name="return")
public Date getLastNotificationDate() throws AffinityException;
...
Actually, you don't even need a servlet container. JAX-WS has a way to run the service under a standalone Java application. It has some limitations (I have failed to make a stateful service work), but it's
very simple to create.
Given that you tagged your question as "Java", I suggest Jetty. It is a very good small servlet engine. It has support for sessions, so adding authentication should not be a problem.
If you are using Java 6, there is already a HTTP Server builtin, it supports Http authentication. That's all you need. Check out,
com.sun.net.httpserver
You could use some restful framework like jersey.
An alternative to SOAP-based web services with JAX-WS would be JAX-RS (for RESTful web services).
We have a lot of scenarios on our project where we want small amounts of data available via simple HTTP URLs while the app is running and in my experience, Restlet (http://www.restlet.org/) seems to be one of the easiest things available for setting up simple "web-service"-like interfaces (RESTful interfaces) within Java apps.