What is the reason for using WADL?

To describe RESTful, we can say that each resource has its own URI. Using HTTP GET, POST, PUT and DELETE, we can work with these resources. All resources are representative. Anyone who wants to use our resources can do this through a browser or REST client.

This is the basic idea of ​​RESTful architecture. This architecture allows you to use services on the Internet. So why is this WADL architecture needed? What does WADL offer for this standard HTTP protocol? Why should WADL exist?

+66
rest wadl
Aug 21 '09 at 13:52
source share
7 answers

The purpose of WADL is to define a contract . The contract indicates how one party can call the other.

When you create a web application from scratch, you do not need a contract and WADL .

When you integrate your system with another system, and you can clearly communicate with your development team, you do not need a contract and WADL (because you can make a phone call so that everything is clear).

However, when you integrate a complex corporate system with several other complex corporate systems supported by several different companies (or federal institutions), then believe me, you want to conclude a contract for communication as strictly as possible. Then you need WADL or Open Specification. Need is bad .

People with a weak corporate background tend to see all of IT as a collection of stand-alone web applications developed independently. But corporate reality is sometimes tough. Sometimes you can’t even call or write to people developing the application with which you must integrate. Sometimes you talk to an outdated application that is no longer supported - it just launches, and you need to figure out how to communicate with it correctly. In such circumstances, you need a contract because it saves your ass .

In fact, customer generation is a secondary feature of contract definition. It is just a toy. The contract obliges bad communicators to clearly communicate integration rules. This is the main reason for using WADL or Open Specification or something else.

+122
May 24 '12 at 7:43
source share

Using WADL implies that you simply can be kind enough to actually identify the data / documents that you pass back and forth. Let's say you pass some XML fragments, they can be part of a specific schema.

Regardless of whether you use DL to generate code, for me this is not very important. In my subjective opinion, it is important that it is important to have a formal agreement on interfaces between business partners. Even if what is transferred is obvious, it helps to determine who should fix what later, if someone changes the previous interface.

The data format is the same part of the interface as the verb names.

+35
Aug 21 '09 at 21:41
source share

WADL appeals to people coming from the SOAP world, where a code generator is usually used to create client code based on WSDL. I don’t think this mechanism is useful in REST because it creates client code that is associated with the server endpoints.

I believe that if you correctly define your media types and use hypermedia in these media types, then there is no need to have WADL. The description of available endpoints is contained in the definitions of the multimedia type. And if you are telling yourself now, but the / xml application does not contain any information about the available hyperlinks, then I say BINGO. Therefore, I do not think that application / xml and application / json are suitable media types for REST. I am not saying that I am not using XML or JSON, just do not use a generic media type name.

Another WADL appeal is for documenting REST services. Unfortunately, this leads developers to the wrong path because WADL is trying to document server-side endpoints. The documentation of REST services should focus primarily on media types. The developer client must be able to write a REST client without knowing any URL other than the root URL.

+25
Aug 21 '09 at 21:30
source share

WADL allows you to generate code, tests, and documentation. There are actually some very useful tools using WADL, here you can see some examples here . The problem with pure REST, as described in the Fielding dissertation, is to write clients that support Hypermedia (for example, to write a Java Swing-based client application). With WADL, this task is fully automated, and this is a huge advantage, in my opinion. Testing is even easier.

+16
Jan 28 '10 at 9:03
source share

Before giving my explanation, let me say that the purest REST extremists will make fun of it to the end of the earth. I do not agree with them, as I would rather do something, but I just know.

WADL is a description of the web services API, a bit like WSDL for web services such as SOAP, which is designed to more accurately interact with RESTful interfaces (something not very similar to WSDL).

The main use in my experience is to allow you to generate client code that can call a service (convenient if it is a very large API, which literally saves hours of work). It also serves to document a REST-like interface.

+14
Oct 26 '11 at 9:14 a.m.
source share
+6
Aug 21 '09 at 14:40
source share

If you want to open REST services, the best way is to create a WADL and share it with the consumer (like WSDL in SOAP-based web services). WADL is used to describe the service in place.

+3
Nov 05 '16 at 13:04 on
source share



All Articles