so is this still considered a "web service?"
I would call that an example of a RESTful web service - assuming that the GET does not change any resource on the server.
WSDL is rather clumsy when describing a RESTful web service - commercial examples seem to prefer descriptive text and coding examples.
This article suggests that in its purest form today, when it's attracting this much attention, a concrete implementation of a REST Web service follows four basic design principles:
- Use HTTP methods explicitly.
- Be stateless.
- Expose directory structure-like URIs.
Keep in mind that in the context of RESTful services, there is no "technical" requirement to use a WSDL instance. Here it is for humans to read only, not computer software.
Nick Watts wrote:If all the parties using a web service understand exactly how to format requests from your web service and parse the response, then you don't technically need a WSDL. However, the WSDL incorporates all of that precise request/response formatting in its definition in a way that is easily digestible by many tools like JAX-WS. Especially with SOAP messages, the WSDL is the key that allows you to use all kinds of tools that know how to deal with web services. So if an informal writeup on your web service's interface is acceptable, you don't have to use a WSDL -- especially if you're not using SOAP messages. If you're using SOAP or you want to use tooling to work with the web service, you'll need a WSDL.
Yep. Tooling is the key word here.
Also lookup WADL - http://en.wikipedia.org/wiki/Web_Application_Description_Language
WADL is not yet widely supported. It has the advantage over the more complicated WSDL in that it does not impose any further level of abstraction on the service description; however, as tools become available for application development with WADL, it is likely they will include ways of automatically generating WADL, and this risks imposing an RPC style on it, going against the intended simplicity of WADL.