I am new to the arena of RESTful services. I have been going through the articles about REST. And I have a lots of doubts. Please help me to clear these doubts. Thanks in advance.
1) For all RESTful web services, will there be a WSDL/WADL for describing the service? Is it mandatory to have service description? If there is no description, how can I know the data and its structure that I have to send along the HTTPRequest?
I read like, the request content could be any type (XML, JSON, YAML etc.). And there is no restriction for the content-type that could be send with request. Without a description how can I know the type of data that I am supposed to send?
2) By going through the articles, I have got the impression that RESTful services is used mainly for CRUD operation kind of services. Different HTTP verbs for different operations. But if you take web services, it can do all kinds of operations. For example, adding 2 numbers is not exactly a CRUD operation. If I use GET/POST to the resource which could do this operations for me, then will it be a violation of REST principles?
3) If you can point me to any public RESTful webservices that could be used for testing, I could try using the service and get an idea how complex the services could be.
Thanks in advance,
Paul
There is normally no machine-readable service description. You would typically know what to send by reading the documentation for the service.
REST isn't limited to CRUD and the PUT/GET/POST/DELETE methods are not necessarily the same as create/retrieve/update/delete. REST-based services can do anything that SOAP-based web services can do. It is completely RESTful to send a GET request to a URI like http://example.com/add?3,5.
You can find a list of REST services at http://www.programmableweb.com/apis/directory/1?protocol=REST.
Answer to your first question :
WSDL/WADL is not mandatory for restful webservices. Also, WSDL 1.1 HTTP binding was inadequate to describe restful webservice.
However, WSDL 2.0 can be used to describe it. Restful webservice should be used when the client and provider have mutual understanding of the contract.
Have a look at : http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/
Second : Yeah, you can accomplish almost everything from crud operations. Like stated in previous answer http://example.com/add?3,5. is a valid crud.
No WSDL/WADL files. You get the HTTP protocol (e.g. GET, POST, UPDATE, DELETE) and everything else is up to you. Make sure to document your expected inputs and outputs accordingly.
No, RESTful web services are not restricted to CRUD. For your adding service, I would implement it as an "adder" resource which would take as input the 2 numbers to add. You could take these inputs as part of the url path (http://yourdomain.com/adder/1/2) or in the query string params (http://yourdomain.com/adder?var1=2&var2=2) or as inputs from an HTTP POST. Up to you.
Related
We are using SOAP based web services to let end user schedule service appointments. Our portal is WebService client & we have a number of Vendors(who are spread across the globe in various timezones) who are building Webservice Server operations.
We are thinking to build it as a contract first SOAP based web services so that we have tight control(interface based e.g. date-time format should be standard xsd:dateTime etc.) over what can be sent & received as part of XML messages for possible success & error scenarios(via different error codes). We want to keep single client code for all the vendors. We would like to determine
1) Should we think about using RESTful web services?
2) Is there any way the vendors can use RESTful services also if they want at their end(by sticking to our WSDL contract) & we use SOAP at our end
First a little bit about,
REST (Representation State Transfer) is an architecture style to develop webservice. In which data and functionality are considered as a resource and can be accessed via URI (Uniform Resource Indicator). It follows client server architecture and uses stateless protocol (usually HTTP). Typically in REST webserivces resources are acted upon by GET, PUT, POST,DELETE operation. Generally we use JSON to exchange data between client and server. It is light weight.
On the other hand SOAP (Simple Object Access Protocol) is a XML based mesaage protocol. Which is generally used on enterprise level to define their own interfacing and operations as services. It also follows REST architecture.
So basically, it is a RESTful webservice.
Now to answer your question,
It seems you are going to expose your webservice client on enterprise level. Which is going to be used by many vendors to implement their own webservice server.
So, it is perfect, you go with SOAP webservices.
You will define the skeleton of the webservice like Message formats, Operations, binding etc which is called WSDL. It is widely used standard and very easy to understand by any third party. Something called WADL is used for REST services also but it is not very user friendly.
The same contract (WSDL) will be used by your vendors to implement the webservice on their server in Top to Bottom approach using some API, for example JAX-WS.
This way you will have a tighter control over your operations, formats, security etc. in a single contract (WSDL).
Now if a vendor wants to use REST webservice instead of SOAP. You can build a JAVA proxy on top of your client. Which will convert your soap messages into REST to send/receive request/response to REST webservices. But you can not dictate your contract in this approach. Although, You can recommend vendors to build their own proxy to handle your SOAP webservice requests. This way your contract will be intact.
If you are going to expose your webservice client for small applications then it is alright to go with REST but if you are an enterprise and going to expand in future, you should go with SOAP for robust features and easy maintenance.
Disclaimer: please do not consider this answer as really serious.
Well, I think question too abstract. Why do you asking it? Because you see yourself that currently everything is RESTful? Then you'r right. You can do any protocol. But if you will do REST with JSON instead of XML, everybody will thank you. And if you will use 40 years old technology for creating modern service, then probably not. Same for your contractors.
The only advantage SOAP seems to have in your situation is that it is already implemented.
SOAP is a complex standard with unfriendly implementation and verbose implementation - i.e. hard to work with and maintain. Also note that you are not even using it "by the book" since your security is external to it and not using ws-security
REST based interfaces would make your and your users' lives easier. I suggest you take a look at standards and tools like swagger for building APIs.If you're running on premise you can take a look at API gateways like tyk If you're running in the cloud you also take a look at AWS API Gateway
I am a novice to web service repository and i want to discover REST based service matching a keyword phrase or some parameters. Is there any repository available like UDDI for SOAP services?
Here are the links where related topics have been discussed
1 How do I discover RESTful Web services?
2 publishing and discovering REST web services
but no where it has been explicitly described how to pursue this task(like a complete tutorial link where RESTFUL web service has been published and retrieved )
Hope to get a well explained answer
Thanks in advance !
It's going to depend on what product are you using for discovery.
MDNS, try using JNDNS for Java. The method you want is probe and you'll have to listen for responses to the query for some predefined String that represents your endpoint. Sometimes people us DNS TXT records or SRV locators for the URL. Here's a good example
UDDI, specifically jUDDI (and 1 or two others) has a REST API that you can invoke. It works well if you know the 'key', or a unique identifier of the service. Since UDDI's data is complex, jUDDI has a FindEndpoints method which can return JSON or XML structures. HTTP GET to http://localhost:8080/juddiv3/services/inquiryRest/{XML,JSON}/endpointsByService/{id}
The response is of type UriContainer, which is just a list of Strings, each representing a valid URL that you should be able to do something with. There's a few more examples in the TCK Tests for juddi here
repository solution can provide some facilities such as service discovery, event notification that a normal DBMS cannot.
For SOAP web services there is a specification which all request/responses must follow. This specification is in the form of a WSDL document. However for REST web services, why is there no such specification or WSDL? Does this make REST more vulnerable to runtime exceptions because we are not following any specifications?
There are bunch of ways to define a RESTful API just like WSDL for SOAP:
Google Discovery service format.
Mashery IODocs.
WADL.
Swagger.
Apiary.
You can find more info here on my blog post.
REST really only uses the HTTP verbs (GET, PUT, POST, DELETE, …) on a resource. All operations on a resource are supposed to be represented that way. POST is used as a catch all for when you can't express your business logic in a way that fits into the other three. That is why there isn't really a WSDL for a REST service since you only ever have 4 methods on the resource.
But you still have the possibility to describe a REST web service with WSDL 2.0.
SOAP is a protocol.
REST is an architecture.
In many references you will see REST and SOAP both mentioned as
competitors. That is not true. SOAP is actually a protocol, not an
architecture style. What REST can be compared against is SOA and RPC.
All three are examples of web service styles, each with their own
conceptual focus. RPC is focused around operations, SOA around
messages, and REST around resources. (ref)
So for SOAP, wrote WSDL document standards. But for REST there is not a standard document, but there is many the best practices be like http://jsonapi.org
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/
When I want to find a "Big" Web service (WS-*/WSDL based) of required functionality I can simply google for ".... filetype:wsdl" because Google indexes also WSDL definitions. Or I can simply use some registries that already crawled the Web for WSDL definitions for me, e.g. SeekDa.com or ServiceFinder.
When I want to find RESTful Web service (RESTful Web API) I may count only on the community, because it is not possible to distinguish between URI of RESTful Web service and other Web resources (e.g. Web sites URLs) and hence any focused crawler cannot tell for 100% sure: this is URI of RESTful Web service. So, I come e.g. to the ProgrammableWeb.com and I hope someone already used/found the service I'm looking for and registered it there.
Recently, I was looking for the Web service for abbreviation expansion. I couldn't find it in portals like ProgrammableWeb, because no-one has put it there. Finally I was forced to browse through several abbreviation dictionaries sites, dig and drill there and I finally found Abbreviations.com Web service API in RESTful form. That took me a lot of time!
Is there any other Way to discover RESTful Web services on the Web?
There is a convention (recommended in REST API Design Handbook for example) that you expose a /api endpoint at the root of your service. This returns an XML or JSON response containing the "child" resources that your service supports e.g. /api/products
The REST ideal is that services are as consumable as Web Pages are, they don't need registries. [Got to admit I don't fully "get" the implications of this RESTful world, no WSDL, no registry feels like riding a bike with no stabilisers.]
In the old Web, pre-Google, how did we find pages? Effectively word-of-mouth and a few key starting points. REST services so far as I can see are pretty much in the pre-Google stage.
I don't agree that "it is not possible to distinguish between URI of RESTful Web service and other Web resources" - if we follow the link we get certain types of content application/xml and application/json would be pretty strong indicators wouldn't they?
There's a WSDL-like file for REST webservices: it's called WADL.
SoapUI now can discover the REST services. It works as a proxy, writing down all requests/responses that pass through. Having requests and responses SoapUI recreates descriptions/definitions of the services.
Now the definitions can be stored in WADL and WSDL formats (as WSDL and XML-Schema in XML world). It also can be stored in Swagger format. I prefer Swagger.
Swagger can be stored in SwaggerHub right from SoapUI, which is like GitHub for source code. SwaggerHub is one of many API management systems.