Is there a way to take any REST API and generate like WSDL document - rest

I know that REST doesn't have WSDL document as SOAP has (some has WADL but not all, and it is not that common)
Is there a tool that take REST documentation (REST uri maybe) and generate describing document for that web service?
The tool swagger https://editor.swagger.io/ is able to do it only if added annotation to the source code of the web service not to any REST web service.

In short there is no official/REST approved way of doing what you are looking for.
WADL, Swagger and RAML are all "proposed" ways of achieving WSDL like functionality in REST, however they are proposed and not wildly supported by the development community.
If you were to start a new project these would make sense but if you want to run it on top of a existing project and generate some documentation you are pretty much out of luck.

Related

How to describe restful webService

I know two types of webservice.
SOAP webservice
restful webservice
SOAP webservice can be described in WSDL.
So restful webservice how to describe, can let people know how to call.
I'm working with documents. Is there anything else like WSDL.
The Bad News:
There is no official way to document REST as you are describing. Also keep in mind a WSDL is used to generate code artifacts as well as document the service.
The good news:
However you can look at the following four options:
WADL: WSDL equivalent for REST(not widely used or accepted)
RAML: Contender as the standard way to document REST and implement code i.e. WSDL equivalent.
Swagger: Documents the REST service. Not really a WSDL equivalent when it first came out. However this has changed recently. See OpenAPI below.
OpenAPI: Is based on Swagger and it is a way to do top down design.
The Ugly News:
Since there is no "official" way some clients will be comfortable with RAML some with Swagger, its is going to be difficult to cater for everyone however this is a minor point.

How do you document the xml structure of a REST API Call?

Like SOAP which as a WSDL which allows you generate code that will help create request, is there any mechanism in REST which allows you to document the payload or response of a REST API call?
Most services that provide REST APIs, seem to provide samples to explain the structure.
What is the best practice for REST APIs.
If you're returning xml, you can simply provide an xsd. There is also wadl, which some frameworks will generate automatically.
I find the best practice is providing samples (or links to samples) to explain the structure. Developers working against your API then need no extra tools or workflows to know how to interact with each part of your service.

How to Create WSDL for Restful WS

I have developed a small RESTful web service example using MyEclipse. I want to create a client for those WS using WSDL. How do I create a WSDL for the above web service using MyEclipse? Please help.
Take a look at this resource. It describes using WSDL 2.0 to describe a REST interface:
http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/#describerestservice
WSDL ? for a REST web service ? i'd suggest you read this book for a better understanding of REST http://oreilly.com/catalog/9780596529260
You don't need WSDL (nor WADL AFAIC) documentation in rest could be plain text for developers, schemas (xsd, rdfs...etc depending on the content types you use) sitemaps for example, a lot of links and post/put templates for example ( to mimic forms in html)

RESTful Services - WSDL Equivalent

I have been reading about REST and SOAP, and understand why implementing REST can be beneficial over using a SOAP protocol. However, I still don't understand why there isn't the "WSDL" equivalent in the REST world. I have seen posts saying there is "no need" for the WSDL or that it would be redundant In the REST world, but I don't understand why. Isn't it always useful to programmatically bind to a definition and create proxy classes instead of manually coding? I don't mean to get into a philosophical debate, just looking for the reason there is no WSDL in REST, or why it is not needed. Thanks.
The Web Application Description Language (WADL) is basically the equivalent to WSDL for RESTful services but there's been an ongoing controversy whether something like this is needed at all.
Joe Gregorio has written a nice article about that topic which is worth a read.
WSDL describes service endpoints. REST clients should not be coupled to server endpoints (i.e. should not be aware of in URLs in advance). REST clients are coupled on the media-types that are transfered between the client and server.
It may make sense to auto generate classes on the client to wrap around the returned media-types. However, as soon as you start to create proxy classes around the service interactions you start to obscure the HTTP interactions and risk degenerating back towards a RPC model.
RSDL aims to turn rest like a hypermedia, in other words, it has more information than a service descriptor like WSDL or WADL. For example, it has the information about navigation, like hypertext and hyperlinks.
For example, given a current resource, you have a set os links to another resources related.
However, i didn't find Rest Clients that supports this format or Rest Server Solutions with a feature to auto generate it.
I think there is a long way for a conclusion about it. See the HTML long story and W3C vs Browsers lol.
For more details about Rest like Hypermedia look it: http://en.wikipedia.org/wiki/HATEOAS
Note : Roy Fielding has been criticizing these tendencies in Rest Apis without the hypermidia approach: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
My Conclusion : Now a Days, WADL is more common that Rest and Integration Frameworks like Camel CXF already supports WADL ( generate and consume ), because it is similar to WSDL, therefore most easy to understand in this migration process ( SOAP to REST ).
Let's see the next chapters ;)
Isn't it always useful to programmatically bind to a definition and
create proxy classes instead of manually coding?
Agree wholeheartedly, this is why I use Swagger.io
Swagger is a powerful open source framework backed by a large
ecosystem of tools that helps you design, build, document, and consume
your RESTful APIs.
So basically I use Swagger to describe my models, endpoints, etc, and then I use other tools like swagger-codegen to generate the proxy classes instead of manually coding it.
See also: RAML
There is an RSDL (restful service description language) which is equivalent to WSDL. The URL below describes its practice http://en.wikipedia.org/wiki/HATEOAS and http://en.wikipedia.org/wiki/RSDL.
The problem is that we have lots of tool to generate code from wsdl to java, or reverse.
But I didn't find any tool to generate code from RSDL.
WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate
However, REST uses the network protocol by using HTTP verbs and the URI to represent an objects state.
WSDLs tell you at this place, if you send this message, you'll perform this action and get this format back as a result.
In REST, if I wanted to create a new profile I would use the verb POST with a JSON body or http server variables describing my profile to the URL /profile
POST should return a server-side generated ID, using the status code 201 CREATED and the header Location: *new_profile_id* (for example 12345)
I can then perform updates changing the state of /profile/12345 using the HTTP verb POST, say to change my email addresss or phone number. Obviously changing the state of the remote object.
GET would return the current status of the /profile/12345
PUT is usually used for client-side generated ID
DELETE, obvious
HEAD, gets the status without returning the body.
With REST it should be self-documenting through a well designed API and thus easier to use.
This is a great article on REST. It really help me understand it too.
WSDL 2.0 specification has added support for REST web services too. Best of both worlds scenario. Problem is WSDL 2.0 is not widely supported by most tools out there yet. WSDL 2.0 is W3C recommended, WSDL1.1 is not W3C recommended but widely supported by tools and developers.
Ref:
http://www.ibm.com/developerworks/library/ws-restwsdl/
The Web Application Description Language (WADL) is an XML vocabulary used to describe RESTful web services.
As with WSDL, a generic client can load a WADL file and be immediately equipped to access the full functionality of the corresponding web service.
Since RESTful services have simpler interfaces, WADL is not nearly as necessary to these services as WSDL is to RPC-style SOAP services.

Grails REST XML API definition

Striving to ship a well documented application, I'm looking for a good way to describe a REST API for my Grails Application users.
I know that REST calls should be simple enough to be described by examples, but it doesn't feel formal enough.
I've spent a couple of hours looking for a solution suggested by other Grails users, but didn't find a neat solution besides a recommendation to use WADL or WSDL 2.0
This looks like a good direction, but there must be a simple way to do it in Grails.
I'd appreciate some guidance for a process to generate a REST API based on my model objects preferably with the ability to filter or control the exposed fields, plus, a nice graphical way to present it (something like the XSD Eclipse plugin)
Thanks!
Guy
I would suggest to avoid WADL or WSDL for API documentation, you can see this question where I explained my reasons: Why the slow WADL uptake.
WADL or WSDL are usually used for automatic client code generation, they are not human readable documentation. I don't think WADL or WSDL are very useful for a user to figure out how to consume the resources correctly.
I prefer the good old html documentation, for example I like the way twitter documented their API
If you insist on automatic generation of resources documentation I can recommend on the ATOM service document. Many REST framework can generate it automatically based on the resources annotations. (e.g. Apache Wink)