I want to ask, what is the difference between OPC UA and REST Web-Service.
I am unable to comment (below 50 points) so small correction to Ramachandran G A statement "OPC-UA was a windows only protocol" -- it was OPC classic. The point with OPC UA is it is multi language, platform independent.
As for the question, you compare two different things in sense REST WS is way more general, it is about how the data are exchanged in broad sense. OPC UA brings "logic" to data exchange -- alarms, events, historic data, filtering, subscription, etc.
[2020 Update] You can convert OPC UA to REST using Open-Plant (FREE)
OPC UA and Rest are totally different protocols. But you can convert OPC UA to REST API using Open-Plant. Open-Plant is a free Industrial IOT Platform. Just download and install it. Once installed there will be a component called OpenPlantOPC which will allow one to access OPC UA via REST API. There should be a REST API guide somewhere in their website
https://www.open-plant.com
Related
I am new to RESTful webservice. Whatever I have read over the internet about RESTful webservice, I came to know that REST works similar to servlet + webservice.
Our traditional webservice looks like JSP-> Servlet -> Service -> DAO -> Database.
Will REST replace Servlet in this heirarchy?
My ultimate goal is that my web application should support mobile application and normal browser also. Is it good idea to use REST in that case. If not, in what situation we should use REST?
I hope my question is clear.
Please help me.
Thanks in advance.
There are many ways we can achieve Machine to Machine communication.
Web services also helps communicating between applications made in different platforms.
For example a .net GUI can call a java server side program for data.
REST is one of that kind, based on HTTP protocol.
SOAP web service is heavy weight (using lots of XML) where as REST is simple and you can expose any of your APIS simply using REST.
A services exposed as REST services can be invoked by a client using on of the HTTP verbs GET, POST, PUT, and DELETE with their meaning same as in HTTP.
RESTful Web Services expose the state of its resources.
An 'Employee' data can be queried and represented in any format (Json, XML ...) using REST.
Rest won't replace the Servlet in your hierarchy, actually the HTTP based REST methods are written on this servlets.
Please go through this URL : http://docs.oracle.com/javaee/6/tutorial/doc/gijqy.html
Using REST is not related to browser experience on mobile or other devices. It totally depends on the client side technology used and your browser compatibility with those technologies.
Using REST is a good idea to access data at client side using simple AJAX calls.
REST means Representational State Transfer. It is a way of thinking about architecting network communication between client and server, with the focus being on transferring a resource from server to client and back again.
To understand the significance of this first consider a different architecture, Remote Procedure Call. This is where the client calls a function on the server as if the function existed on the client.
So you want to edit a photo that exists on the server. Your client is a photo editing app that uses RPC to achieve this. You want to blur the photo so your client calls the blur() function using RPC, and the server blurs the image and sends back the updated image. Then you want to rotate the image, so your client calls the rotate() function and the server rotates the image and sends the rotated image to your client.
You might have noticed two issues. Firstly, every time you carry out an action on the photo the server needs to do some work and send you back the updated image. This uses a lot of bandwidth.
Secondly what happens if tomorrow the server developers (who might be nothing to do with the client developers) decide that rotate() is the wrong function name, it should really be rotate_image(), and they update the server. Your client continues to call rotate() but this now fails because such a function doesn't exist on the client.
REST is an alternative way of thinking about client/server communication. Instead of telling the server to carry out an action on the resource (eg rotate the photo), why doesn't the client not just get a representation of the resource and carry out all the actions it wants to (blur, rotate etc) and then send the new state of the resource back to the server.
If you did it this way the protocol to communicate between client and server can be kept very simple and will require very few updates. All you need is functions for the client to get the resource and functions to put it back on the server. The client will have to know how to blur the image and rotate the image, but it doesn't need to know how to tell the server to do this, it just needs a way of telling the server to save the updated image.
This means that the developers of the client can work away implementing new features independently to the developers of the server. Very handy if the developers of the client are nothing to do with the server (the developers of Firefox have nothing to do with the New York Times website and vice versa)
HTTP is one such protocol that follows this architecture pattern and it allows the web to grow as it has. There are a small set of verbs (functions) in HTTP and they are concerned only with transferring a representation of the resource back and forth between client and server.
Using HTTP your photo client simply sends a GET message to the server to get the photo. The client can then do everything it wants to to the photo. When it is finished it sends the PUT message with the updated photo to the server.
Because there are not domain specific actions in the protocol (blur, rotate, resize) this protocol can also be used for any number of resources. HTTP doesn't care if the resource is a HTML document, a WAV file, a Javascript script, a PNG image. The client obviously cares because it needs to understand the resource it gets, and the server might care as well. But the protocol between the client and server doesn't need to care. The only thing HTTP knows is that there is a variable Content-Type in the HTTP header where the server can tell the client what type of resource this is.
This is powerful because it means you can update your client independently to updating your server without updating the transfer protocol. HTTP hasn't been updated in years. HTML on the other hand is updated constantly, and web servers and web browser are updated constantly (Chrome is on version 33). These updates can happen independently to each other because HTTP never (rarely) changes.
A web browser from 10 years ago can still communicate with a modern web server over HTTP to get a resource. The browser might not understand the resource, say it gets a WebM video that it can't understand, but it can still get this resource without the network communication failing.
Contrast that with the example of RPC above where the client server communication will break if the server changes rotate() to rotate_image(). Every single client will have to be updated with this new function or they will crash when trying to talk to the server.
So REST is a way of thinking about client server communication, it is an architecture design/pattern. HTTP is a protocol that works under this way of thinking that focuses on simply transferring state of a resource between server and client.
Now it is important to understand that historically a lot of people, including web developers, didn't get this. So you got things like developers putting verbs into resource names to try and simulate Remote Procedure Call over HTTP. Things like
GET http://www.mywebsite.com/image/blur_image
And they would hard code the URI /image/blur_image into their client and then try and make sure the guys developing the server never changed the URI blur_image. You get back to all problems of RPC. As soon as the server guys move the resource blur_image (which is not really a resource to start with) to /image/blur_my_image the client falls over because it has that hard coded as an action to perform, rather than simply getting /image and doing what ever it wants to it.
So there are lot of examples on the web of doing REST wrong. Anything that tightly couples client and server communication is doing REST wrong. Your client should be able to survive URIs changing, or Content-Types being updated, without falling over. It can complain it doesn't understand a resource (eg Netscape Navigator 2.0 complaining it has no idea what a HTML5 document is), but it should complain that a URI has changed. This is the discoverability aspect of REST, which I haven't gone into too much, but basically your client should be able to start at the root of the server http://www.mywebsite.com and if it understand the content types it should be able to continue on to the resource it wants. You should never need to hard code a URI into your client other than the root of the server.
I could write a book about this stuff (and many have), but I hope that serves as a good introduction about what REST actually is.
#javafan I just checked the mykong example you provided. Please note that that is not standard http servlet implementation, it is a Jersy way of implimentinmg rest. So when you map all your URIs goes through this servlet com.sun.jersey.spi.container.servlet.ServletContainer and you write classes with annotation #path etc the Jersy runtime environment will do the necessary processing for you like converting the input and output objects to necessary formats (json, xml etc) depending on your configuration. You can write a simple servlet and add methods in it with #path annotation in it and that will be invoked inturn when you make the corresponding request. but the doGet and doPost methods are standard servlet methods that processes GET and POST method by default. You can ad another methods to the same servlet and add more qualifiers to process your request.
#GET, #Produces("xml") etc.
I hope this helps.
I am not sure if this is the correct place to ask but since there are a lot of questions of this kind i ll go ahead and ask.
A year ago i developed an iOS application that was connecting to a server with HTTP requests exchanging JSON files etc. I was told at that time that the server was a web (REST) service. I didnt care much since for me was just a black box.
The last months i am developing a hybrid mobile application where i use native code + jquery mobile for the front end part and php + mysql for the back end part. The application is about registering new users to the data base , having users to subscribe in various kinds of events , get notifications on them etc. So for all the communication between the front ent(client) and back end(server) i make http requests(POST) , ajax calls using json files.
Is this a RESTfull Web Service? I am a bit confused on the definition of REST. According to wikipedia REST is :
REST-style architectures conventionally consist of clients and servers. Clients initiate requests to servers; servers process requests and return appropriate responses.
So is what i am building a Restfull Web Service? Also do we call Rest only the server part or in general the client-server architecture?
Is it just a web Service? And if yes what kind of web service?
there is no difference when you invoke a controller (aka web service) from browser through http or from a client code (java, .NET or any language). when you want to invoke a service from outside world from your code.. you have choice of soap or rest .. soap is protocol, where as REST is an architecture style.. so REST is methodology of calling a service (which is simple http POST or GET call) from outside world .. not necessarily from a browser .. it may from client code which acts as browser to get response from outside world service..this is based on my experience..
I've started learning about webservices recently. Have few question about that:
For webservice, is it always necessary that source should provide wsdl or any other way possible to consume it without needing wsdl?
Till a while ago, I was doing server side XMLhttp post in classic ASP to do modifications in external application & to push data in my application from external application. I'm confused - is that very different from webservice or can be called a sort of webservice(ofcourse without based on SOAP). Any major difference or it is just protocol difference bw webservice and server side XMLhttp post?
Web services can be made asynchronous?(Something like AJAX call through javascript)
Are there any different types of webservices ? (for e.g is there difference bw, webservice providing stock quotes and webservice provided by google)
1.For webservice, is it always necessary that source should provide wsdl or any other way possible to consume it without needing wsdl?
WSDL is a document that publishes an interface. As long as a client complies to the inteface, it is guaranteed to be able to "talk" to the web service. Having said that WSDL is a formal way for a specification when there are many stakeholders. You can proceed without one, as long as you somehow know what the web service expects. Just wrap the application data in a SOAP envelope and send it to the web service. As long as you send what the web service expects (in the SOAP envelope or the application data) and in the way they are expected e.g. transport HTTP etc. it does not matter for the WS if you have used a WSDL or not.
2.Till a while ago, I was doing server side XMLhttp post in classic ASP to do modifications in external application & to push data in my
application from external application. I'm confused - is that very
different from webservice or can be called a sort of
webservice(ofcourse without based on SOAP). Any major difference or it
is just protocol difference bw webservice and server side XMLhttp
post?
In very simple terms web service is XML over some application protocol (usually HTTP). Could be SOAP based or REST. To understand more on this you should read about Service Oriented Applications
3.Web services can be made asynchronous?(Something like AJAX call through javascript)
They could but it is more complicated than that.
4.Are there any different types of webservices ? (for e.g is there difference bw, webservice providing stock quotes and webservice
provided by google)
Not sure what you ask here. Each web service offers something.
I will try to be very simple here:
The W3C defines a "Web service" as "a software system designed to
support interoperable machine-to-machine interaction over a network".
That means first requisite for any software to be web-service is that it should not depend upon platform or software i.e a web service made on java stack can be consumed by client in .net stack on windows or java stack on android.
If your server side implementation XMLhttp post suffice this ,its a
web service.
Types of Web services
Actually, there is no overall and clear categorization on types of web services. But two most popular are :
SOAP based web services. :It use XML messages that follow the Simple Object Access Protocol (SOAP) standard, an XML language defining a message architecture and message formats(WSDL).
REST based web services. With evolution of WEb 2.0 emphasis has been moving away from SOAP based services towards representational state transfer (REST) based communications.[3] REST services do not require XML, SOAP, or WSDL service-API definitions.Read here to get a easy explanation of REST
Need of WSDL to consume SOAP web services?
To consume a SOAP service we only require SOAP endpoint and XML message format. WSDL is a pre-requisite for automatic client side code generation through Java and .NET SOAP frameworks.
Asynchronous web services
Making web services asynchronous is possible.But complexity depends upon frameworks used, for example AXIS2 in JAVA has easy implementation of this.
What is WSDL? How is it related to SOAP? Where does REST fit in all of that?
A WSDL is an XML document that describes a web service. It actually stands for Web Services Description Language.
SOAP is an XML-based protocol that lets you exchange info over a particular protocol (can be HTTP or SMTP, for example) between applications. It stands for Simple Object Access Protocol and uses XML for its messaging format to relay the information.
REST is an architectural style of networked systems and stands for Representational State Transfer. It's not a standard itself, but does use standards such as HTTP, URL, XML, etc.
Example: In a simple terms if you have a web service of calculator.
WSDL: WSDL tells about the functions that you can implement or exposed to the client. For example: add, delete, subtract and so on.
SOAP: Where as using SOAP you actually perform actions like doDelete(), doSubtract(), doAdd(). So SOAP and WSDL are apples and oranges. We should not compare them. They both have their own different functionality.
Why we use SOAP and WSDL: For platform independent data exchange.
EDIT: In a normal day to day life example:
WSDL: When we go to a restaurant we see the Menu Items, those are the WSDL's.
Proxy Classes: Now after seeing the Menu Items we make up our Mind (Process our mind on what to order): So, basically we make Proxy classes based on WSDL Document.
SOAP: Then when we actually order the food based on the Menu's: Meaning we use proxy classes to call upon the service methods which is done using SOAP. :)
Every time someone mentions SOAP/WSDL, I think of objects and classes defined in xml...
"You use SOAP just the same way that you would any PHP class. However, in this case the class does not exist in the local applications file system, but at a remote site accessed over http."
...
"If we think of using a SOAP service as just another PHP class then the WSDL document is a list of all the available class methods and properties. "
http://www.doublehops.com/2009/07/07/quick-tutorial-on-getting-started-with-soap-in-php/comment-page-1/
..and whenever someone talks about REST I think of HTTP's commands (request methods) like POST, GET and DELETE
SOAP -> SOAP(Simple object access protocal) is the application level protocal created for machine to machine interaction. Protocol defines standard rules. All the parties who are using the particular protocol should adhere to the protocol rules. Like TCP, It unwinds at transport layer, The SOAP protocol will be understood by Application layer( any application which supports SOAP - Axis2, .Net).
WSDL -> SOAP message consist of SoapEnevelope->SoapHeader and SoapBody. It doesn't define what would be message format? what are all the transports(HTTP,JMS) it supports? without this info, It is hard for any client who wants to consume the particular web service to construct the SOAP message. Even if they do, they won't be sure, it'll work all the time. WSDL is the rescue. WSDL (Web Service description Language) defines the operations, message formats and transport details for the SOAP message.
REST -> REST(Representational state transfer) is based on the Transport. Unlike SOAP which targets the actions, REST concerns more on the resources. REST locates the resources by using URL (example -http://{serverAddress}/employees/employeeNumber/12345) and it depends on the transport protocol( with HTTP - GET,POST, PUT, DELETE,...) for the actions to be performed on the resources. The REST service locates the resource based on the URL and perform the action based on the transport action verb. It is more of architectural style and conventions based.
You're not going to "simply" understand something complex.
WSDL is an XML-based language for describing a web service. It describes the messages, operations, and network transport information used by the service. These web services usually use SOAP, but may use other protocols.
A WSDL is readable by a program, and so may be used to generate all, or part of the client code necessary to call the web service. This is what it means to call SOAP-based web services "self-describing".
REST is not related to WSDL at all.
SOAP stands for Simple (sic) Object Access Protocol. It was intended to be a way to do Remote Procedure Calls to remote objects by sending XML over HTTP.
WSDL is Web Service Description Language. A request ending in '.wsdl' to an endpoint will result in an XML message describing request and response that a use can expect. It descibes the contract between service & client.
REST uses HTTP to send messages to services.
SOAP is a spec, REST is a style.
Wikipedia says "The Web Services Description Language is an XML-based language that provides a model for describing Web services". Put another way, WSDL is to a web service, as javadoc is to a java library.
The really sweet thing about WSDL, though, is that software can generate a client and server using WSDL.
Some clear explanations (for SOAP and WSDL) can be found here as well.
Difference between a SOAP message and a WSDL?
REST is light-weight in terms of encoding, much more useful for light weight devices i.e. non strict APIs.
REST is format independent. XML, HTML, JSON all options are available.
REST provides abilities for on 2 point message transfer (not surprising since REST stands for REpresentational State Transfer) where WSDL/SOAP interaction is multiple point message interaction.
REST does not require a new extension for XML messages, where in WSDL/SOAP this is the case.
WSDL/SOAP uses multiple transport protocols, REST relies on only HTTP. Therefore WSDL/SOAP can be used like a RESTful way, however simple requests can be overly complicated/heavy weighted.
A simple analogy: REST is like a motoboy delivers your food easy and quick. XML extended WSDL/SOAP more like UPS delivery, more structured and serious stuff but comes with a cost.
A WSDL document describes a webservice. It specifies the location of the service and the methods of the service using these major elements:
data types using in webservice
data elements for each operation
describe the operations that can be performed and the messages envolved
SOAP (Simple Object Access Protocol) is a messaging protocol that allows programs that run on disparate operating systems to communicate using http and xml.
I feel the term "webserver communication" is not right when it comes to just accessing an server to retrieve information.
Example:
iPhone connects to http://foobar.foo/bar.php?foo=bar&bar=foo and receives an XML. XML is parsed on the iPhone.
iPhone connects to some server and sends some instructions + data to store some stuff there. Lets say XML-RPC or something like that. Server processes that stuff, saves it and sends a response like "OK".
You get it...iPhone talks to server, server talks to iPhone. For me, Webservice and Webserver is the same thing, both are called with an URL and both respond something.
So waht's the correct term when I wanted to mention this sort of thing when talking to a computer scientist (studied)?
"Webservice communcation"?
"Webserver communication"?
"Call"? ... i mean... yeah you know what I mean. I hope so ;)
note:
1) my english is bad
2) never studied cs
That would be a Web Service Call.
A Web Service is a Service (that serves data) and it runs on a Web Server (the actual hardware running the software).
Well I don't know any better way to describe it as a Web Service...
What you have described is a classic case of a 'Web Service'... Just because you don't like calling a sheep a sheep doesn't stop it from being a sheep.
Also imho a web service is very different to a web server.
I think any of these would be fine:
Web request (if it's HTTP, FTP, other "web protocol")
Network call/request (more generic)
HTTP request (if you want to be specific about HTTP)
Web service call (web services are associated with SOAP/XML a lot of times, but the term applies to any web-base service call)
For generic cases, I usually use transmit or receive when I need to be more specific than saying communicate.
The term you are looking for is HTTP request.
The specific technique you are using (javascript/xml through the browser) is called AJAX.
I've heard/used:
Web Services (generically)
XML over HTTP (based on your specific description)
Other paradigms pertain to implementation of Web Services using specific technologies/protocols such as:
SOAP
XML-RPC
REST
What you've described here may actually be one of these specific technologies, but there's not enough information to determine this based on your post.