I'm new to REST webservices I build successfully a RESTful service and a client. I wonder, that I can't find the opportunity to generate my entities automatically on the client side. That means I have to provide all entities to client (e.g as jar lib).
Is it really the only way?
I have worked with SOAP Webservice and the entities were generated automatically on the client side. So I think I'm missing something.
If your REST service(s) support XML, you can provide clients XSDs of your data model, which provides them a widely-supported mechanism to generate your entity classes in their environment.
WADL is nice to define REST operations but it unfortunately does not cover the entity definitions, so it would not help you much there.
Related
I am new to Rest web service and while learning it a question strikes me,
In SOAP based web service, WSDL is act as a contract between client and service provider, so, Client will know how to interact with service provider by reading the WSDL file and create a client which is highly capable of interacting with service provider. To my understanding, in Rest web service we don't have WSDL so how a client will generate its stub automatically?
In REST, clients are not generated automatically, in general. There is something called WADL, which is sort of "WSDL for REST", but it's not a standard yet and may never become a standard. But in general, all REST clients need to be created without the use of metadata from the service.
I like all the features that JayData provides. I am wondering for when I occasionally have a non-O-Data restful service if there is a way to manually hookup CRUD ops to my existing jaydata entity definitions so that I can take advantage of all the kendoui/knockout goodness that comes with this.
Is there any example where a jaydata entity definition is manually hooked up to restful service url kind of like the jquery method?
Thanks
Our webapi provider is what your are after. Do not worry about its name, webapi is a microsoft framework for rest apis, hence the name, but it should work with other restful endpoints, php, java, ruby, etc. Of course it is only good for crud, as filtering, paging, ordering and projection is only standardized in odata. Also, for paging length() is needed, so that must be implemented on the server side, too.
Give it a try and tell us about your experience, good or bad, we're to help you.
Or consider using oData, JayData can act as an odata endpoint on the server side, we also have hosted odata service.
I am working with a CRM System that provides two types of APIs: servlet API & REST API, both of which are over HTTP.
I used to integrate with REST API from my ASP.NET MVC web application by calling the REST URL and manipulating the returned JSON or XML. But I cannot figure out what is meant by a servlet API and can these APIs be called over the web from my ASP.NET MVC application or these APIs should be called inside a Java application?
Sorry if my question seems trivial to someone.
The Java Servlet API refers to a set of classes used to implement server side programs. The main player is the Servlet:
A servlet is a small Java program that runs within a Web server. Servlets receive and respond to requests from Web clients, usually across HTTP, the HyperText Transfer Protocol.
If you want a very simplistic analogy, the Servlet is Java's version of CGI (Common Gateway Interface).
A REST API is a way to build applications by fully using the architecture of the web. Leaving all details of REST aside and grossly simplifying, it's basically a HTTP API.
If you want to build a HTTP API, you can use Servlets. So you can also use servlets to build a REST API although there are better alternatives to that (e.g. JAX-RS) because servlets are a "low level" component and nothing shields you from all the boiler plate code you need to write.
You can of course call a Java application build on top of the Servlet API from other clients (e.g. from ASP.NET MVC). That's what it was built for. For this reason I don't really understand what exactly your CRM system means by a Servlet API and (a separate!?) REST API... so maybe ask the CRM provider?
EDIT : Based on what I've read about the ManageEngine Service deskPlus APIs, I'm thinking that this is just an unfortunate name chosen by the provider.
As I mentioned in my comments, when you say REST API you already provide some information from the beginning. Most people, when told about REST understand that you have some abstract resources, that these resources can have multiple representations (JSON, XML, whatever), that each resource is identified by a URI, that /customers is referring to a list of customers resources, that /customers/1 is a customer and that /customers/2 is another one, that you use GET /customers/1 to find out details about the customer and DELETE /customers/1 to delete it etc.
REST is one way to interact with an application, another one is to expose operations that can be called by clients, for example like what SOAP is doing. Before REST became the new kid in town people were doing stuff with SOAP. Unlike accessing resources, SOAP is focused on accessing operations. When you mention SOAP to someone she knows that it's a protocol that can use HTTP's POST to transmit messages around, that each message has an XML payload that contains the operation name to invoke and the parameters needed for the call etc.
But even before SOAP and REST becoming widely known, people realized that they can use a form submit to sneak in RPC calls through HTTP. The HTTP form based submission is one of the methods of the API in ManageEngine Service deskPlus. But the form based submission method (as far as I know) doesn't have a cool name like SOAP or REST... so maybe that's why it was named after the Servlet API?! (I'm once again emphasizing that this is just the server implementation which is not important in the context of the HTTP protocol).
So to conclude: Yes, you CAN call the ManageEngine Service deskPlus Servlet API from ASP.NET, even a web browser or any kind of HTTP capable client.
I'm a seasoned Java developer but new to GWT.
Consider a 3rd party http POST based webservices api, not completely REST based since there's configuration of servlets, among other things, to invoke these services. I'm building gwt components extending the base gwt composites and using these 3rd party data services to fetch/mutate the data.
In the normal java world, I'd have build a REST wrapper on these services and exposed them as Pojos via JaxB Xml/Json. In GWT, however, I read GWT-RPC will be the fastest, given the serialization required. The data is expected to be large (several thousands, paginated).
What's the best way to design the 'bridge' between the 3rd party data services and the gwt client components?
I ruled out RequestFactory since we have a custom servlet provided by the 3rd party that fetches the webservices.
Adding a rest wrapper adds a 3rd layer of indirection (3rd party api+rest+gwt-rpc serialization) that felt too heavy
Suggestions for a low latency design, where I don't have to write too many wrapper classes for each service call (pojo)?
I'd like to consider jaxb on the server side, making schema as the new contract, and converting them to JSON for gwt-client.
I am using RestEasy on the server side, which uses Hibernate JPA to access database. With a little modification, I should be able to switch over to Datanucleus JPA.
I am using RestyGWT on client side.
With careful consideration on the DTOs, I am able to
- share the same DTO between server and client
- share the same REST interface between server and client (after running a script over the server side REST interface to transform the return type into an async callback).
Integrating multiple GWT applications into a pluggable platform.
Currently I am also trying to merge JPA DTO with REST DTOs so that I have a single set of POJOs between server, database and client. Each DTO POJO would therefore have a mix of JAX-RS, JAXB, Jackson JSON and JPA annotation.
To reduce unnecessary client-server traffic, I use JSP as GWT hosting file in tandem with GWT Dictionary class to transfer all session-specific session-static information to the client.
My Suggestion would be to use Spring RestTemplate, Gwt-RPC and have a RemoteServiceServlet/Spring bridge - that would give you RPC calls via a POJO from Server-Client and a clean tier to communicate with your external web services..
This will be lightweight and clean..
I must admit that I'm new to Web services. When I create a Web service using CXF or Axis, even with custom beans being used to communicate information between the client and the service, the objects are automatically marshalled and unmarshalled for me (I mean CXF or Axis create all the necessary files and classes). So, even though I know JAXB is used by the stack to marshal, and unmarshal objects, but I don't directly need to work with JAXB.
Now, my question is whether I need to work with JAXB directly, as far as Web services are concerned, or that marshaling and unmarshalling will always be handled for me?
When creating a JAX-WS (SOAP) or JAX-RS (RESTful) Web Service, JAXB is used as the binding layer to convert objects to/from XML (and sometimes JSON). This marshalling/unmarshalling is triggered automatically for you. Where you interact with JAXB is by adding annotations to your domain model to control how the XML looks. Below are a couple of examples that you may find useful:
http://blog.bdoughan.com/2011/12/eclipselink-moxy-is-jaxb-provider-in.html (JAX-WS example)
http://blog.bdoughan.com/2010/08/creating-restful-web-service-part-35.html (JAX-RS example)