Tech Stack: Java 1.6, JPA (Hibernate 3), Spring 3, Oracle 11g
Hello,
In one of my projects, we have to create a number of web services.
These web services are like 'create application' and 'udpate application'.
For creating an application, the input data (request XML) is around 90-100 lines.
In my view I should be using SOAP\XML webservice (Spring), but my company has decided to go forward with REST (JAX-RS).
I think it will be difficult for client to create such request without any formal contract.
Or do you think REST will serve the purpose?
Thanks,
Adi
REST is much more flexible then SOAP. with REST service you can return responses as XML/JSON/HTML while in SOAP its usually just XML.
REST also uses plain HTTP unlike SOAP which extends HTTP.
So your company did the right choice. Regarding the format of the answer, if it's JSON, you can use libraries like Gson to convert messages. You'll need to write a document describing the different links and their input/output (look here for example)
If it's XML, all you need is an XSD for the request/response and again use a FW like XmlBeans to Marshal/Unmarshal the request/response. In that case, just give the client the XSD's and the above mentioned document.
Related
Webservices like REST, SOAP which provides services which is made available for web application, as we know it can receives values as JSON, string, XML etc either by POST or GET and in the same way it can return data as JSON, string, XML etc.
The same thing can be done via servlet, as servlet can receive data as string, JSON etc either by POST or GET and in the same way it can return data as JSON, string, XML etc.
We need libraries based upon the web service we use, such as SOAP or REST, servlet libraries are almost in-built int it.
So whats the difference between Servlet and Web Services? Which one is more faster?
Can anyone please tell me some solution for this.
This is the kind of discussion that can lead to a lot of flame wars on semantics, but I would say web services are simply a method of communication utilizing standards to allow different technologies to be interoperable. Like an English-speaker translating between a French- and German-speaker.
Meanwhile, the way to implement web service endpoints (the places that serve responses to your requests) in a Java web server is with servlets. So servlets are simply a technology for implementing web service communication (in the JVM).
When you look at JAX-WS and JAX-RS, the frameworks that implement these standards are simply creating abstractions on top of Java's HttpServlet (typically) to make SOAP and REST web services easier to build by taking care of a lot of the low-level details.
Hope that helps.
where are a lot of difference between servlets and web services, but the main is:
in the web development servlets is the front end object and work in the web container, Web services can have different roles: as backend or as middle layer object.
There are 2 types of web-services as I know. First one is custom xml formatted messages and the second one SOAP standard xml messages. What are the differences between them? Which one is better, what are pros and cons of each of that two approaches?
By "ordinary" I assume you mean RESTful services. This discussion would be a long one, so I'll try to give you some key points:
RESTful services are the most used flavor of Web Services. They are closely linked to the functionality and principles of HTTP and can be accessed as simple as a GET request (other operations are POST, DELETE and PUT). The core concept is the "resource" which is identified by an URI. Common formats for REST are XML and JSON. It's a pretty straightforward and easy to use technology, which is what makes it so widely available.
SOAP web services are based on XML, most of them adhering to the RPC-style of app design (calling remote methods on a server and getting a response), and use 3 main pillars:
WSDL - Web Service Description Language - used to describe a service in terms of available operations, parameters, etc.
SOAP - Simple Object Access Protocol - used to construct interaction messages between the entities involved (client, server).
UDDI - Universal Description, Discovery and Integration - used to classify and publish available web services to a repository and enable discovery by potential users.
SOAP Web Services tend to have high overhead and generally have very verbose messages, but may be good if you need to implement more complex functionality and interaction in your application.
Strictly speaking only the Soap services are webservices. They are based on the WS-* Specs standardisized by W3C and Oasis. Sometimes a also reffered as Webservice are so called POX-Endpoint (Plain old XML) or REST Endpoint, which allows you to simply get a raw XML via HTTP GET.
SOAP Services carry their schema in form of a wsdl endpoint (usualy append ?wsdl to the service endpoint), so there a lots of tools to create proxy objects and hide the complexity of the webservice call. With POX Services you need to know which schema to use from e.g. the documentation.
SOAP Services carry the payload inside the SOAP Envelope (an XML Schema with header and body with the payload in the body). Having a header independent from the payload allows to reroute the content, sign and encrypt, authenticate etc. without knowing the content. But you pay by additional overhead in the message itself.
POX on the other hand leaves all that to the webserver and relies usualy on HTTP for authentification and compression. Encription and signing had to be done by your system. It is low overhead but also low discoverability.
Whats works best for you depends a lot on your scenario. If you work in a .Net or Java World, you often find it simplest to create a proxy and use that to work with the webservices as remote objects. You get a well build infrastructure and a comfortable programming experience. If youre environment does not support the proxy generation or if it had to be called from anything, POX might the very much more lightweight way to go.
"Web Service" refers to a more abstract and general concept. We can say that anything that can be served on web is a Web Service. SOAP Web Services or RESTful services are special kind of Web Services which has wide acceptance and has their own standards. While SOAP services are built on a new XML based standard, RESTful approach makes use of existing HTTP methods, hence more widely accepted (to my experience).
Situation:
We are planning to build a set of new services a long side a set of old SOAP (Spring, apache CXF) web services. Our customers are used to being able to use ?wsdl to get a wsdl describing a service and the content it will accept/return.
I'm looking at providing the new services via spring controllers and RESTful urls. However not all of a request can be handled via a RESTful url, so we still need to have a payload request and responses. I'm looking at use #RequestBody and #ResponseBody and spring's Message Converters to auto(magically) handle both XML and JSON content. The idea being to let spring do as much of the heaving lifting as possible.
The problem:
I'm trying to figure out if it's possible given the REST/Message converter concept, to be able to provide a description of a service and it's request/response data in a similar fashion to the ?wsdl request. I understand that there are WADL documents that can be generated by some systems, but they appear to be a proposel and not fully accepted yet.
Does anyone know if spring can generate WADLs or something else that I can use to allow clients to query the RESTful services data structures?
SpringMVC doesn't support WADL auto generation, mostly because it doesn't use the JSR-311 standard REST API.
I have create a blog entry with a simple WADL generation Controller in java :
Tuxgalaxy Blog Entry.
But Tomasz Nurkiewicz also provide a WADL generation Controller in scala :
nurkiewicz Blog Entry.
You could use CXF JAX-RS for your REST services since you're already using it for SOAP (you can even expose the same service as SOAP and REST with CXF), and CXF gives you the WADL that you want by adding ?_wadl&_type=xml
The following code will work with Spring REST 4x and its based on the suggested code by tuxgalaxy provided on below https://jira.spring.io/browse/SPR-8705
http://javattitude.com/2014/05/26/wadl-generator-for-spring-rest/
This is actually a design question.
I'm wondering if Spring3.0 REST web services that carries JSON payload provide some kind of data contract similar to traditional web services which follows contract-first design.
I know that JSON has schema similar to XSD but where does it fits in spring ?
Background:
I consider using json as the payload of a client server architecture project where the client is .NET based application and data contract should provide a way to handle multiple versions of the client. The client should be able to post data structures to the server.
Or maybe I should take a schema-less approach and use "Simple Data Binding" which is similar to XmlAnyElement?
The "contract" with "regular" web-services is defined in WSDL files (which include XSDs). With RESTful services these files are called WADL. And spring-mvc does not have support for generating WADLs. (JAX-RS implementations have).
But even if if did, RESTful services are considered more "dynamic" and they don't need to be fixed like that. For example take a look at Facebook's and twitter's REST APIs. They don't provide WADLs or JSON schemas. They provide some free-form documentation of their services. That should be sufficient.
If clients should be enabled to mock the services for unit testing the client (and actually they should), the services should provide a contract. Free form documentation is not a reliable base for testing, because it leaves space for misunderstanding, while contracts don't.
JSON Schema and Hyper-Schema are JSON Schema formats for specifying content and content negotiation.
I have been working on a HATEOAS (Hypermedia as the engine of application state) API, using JSON Hyper Schema.
You can go to the URL below, browse around, register, login and do some actions.
Check it out, here:
http://direct.psprt.com:8081/
I also open sourced my actual API code thus far:
http://bpanahij.github.io/passportedu_schema/
Feel free to take a look, borrow, and comment.
Also, check out the Javascript JSON-Hyper-Schema client. It dynamically builds an HTML client app using Angular, by parsing the Schema provided at a given resources endpoint with the OPTIONS method.
https://github.com/bpanahij/passportedu_schema/tree/master/client
What is the difference between OData and REST-ful web services?
UPDATE Warning, this answer is extremely out of date now that OData V4 is available.
I wrote a post on the subject a while ago here.
As Franci said, OData is based on Atom Pub. However, they have layered some functionality on top and unfortunately have ignored some of the REST constraints in the process.
The querying capability of an OData service requires you to construct URIs based on information that is not available, or linked to in the response. It is what REST people call out-of-band information and introduces hidden coupling between the client and server.
The other coupling that is introduced is through the use of EDMX metadata to define the properties contained in the entry content. This metadata can be discovered at a fixed endpoint called $metadata. Again, the client needs to know this in advance, it cannot be discovered.
Unfortunately, Microsoft did not see fit to create media types to describe these key pieces of data, so any OData client has to make a bunch of assumptions about the service that it is talking to and the data it is receiving.
The OData protocol is built on top of the AtomPub protocol. The AtomPub protocol is one of the best examples of REST API design. So, in a sense you are right - the OData is just another REST API and each OData implementation is a REST-ful web service.
The difference is that OData is a specific protocol; REST is architecture style and design pattern.
REST is a generic design technique used to describe how a web service can be accessed. Using REST you can make http requests to get data. If you try it in your browser it would be just like going to a website except instead of returning a web page you would get back XML. Some services will also return data in JSON format which is easier to use with Javascript.
OData is a specific technology that exposes data through REST.
If you want to sum it up real quick, think of it as:
REST - design pattern
OData - enabling technology
In 2012 OData underwent standardization, so I'll just add an update here..
First the definitions:
REST - is an architecture of how to send messages over HTTP.
OData V4- is a specific implementation of REST, really defines the content of the messages in different formats (currently I think is AtomPub and JSON). ODataV4 follows rest principles.
For example, asp.net people will mostly use WebApi controller to serialize/deserialize objects into JSON and have javascript do something with it. The point of Odata is being able to query directly from the URL with
out-of-the-box options.
From the OData documentation:
The OData Protocol is an application-level protocol for interacting with data via RESTful web services.
...
The OData Protocol is different from other REST-based web service approaches in that it provides a uniform way to describe both the data and the data model.
OData (Open Data Protocol) is an OASIS standard that defines the best
practice for building and consuming RESTful APIs. OData helps you
focus on your business logic while building RESTful APIs without
having to worry about the approaches to define request and response
headers, status codes, HTTP methods, URL conventions, media types,
payload formats and query options etc. OData also guides you about
tracking changes, defining functions/actions for reusable procedures
and sending asynchronous/batch requests etc. Additionally, OData
provides facility for extension to fulfil any custom needs of your
RESTful APIs.
OData RESTful APIs are easy to consume. The OData metadata, a
machine-readable description of the data model of the APIs, enables
the creation of powerful generic client proxies and tools. Some of
them can help you interact with OData even without knowing anything
about the protocol. The following 6 steps demonstrate 6 interesting
scenarios of OData consumption across different programming platforms.
But if you are a non-developer and would like to simply play with
OData, XOData is the best start for you.
for more details at http://www.odata.org/
ODATA is a special kind of REST where we can query data uniformly from URL.
REST stands for REpresentational State Transfer which is a resource based architectural style. Resource based means that data and functionalities are considered as resources.
OData is a web based protocol that defines a set of best practices for building and consuming RESTful web services. OData is a way to create RESTful web services thus an implementation of REST.