Hacker News Reader

Comment by swalsh | Hacker News Reader

Very cool, it feels like WSDL for REST

EDIT: spelling

It's funny how trends in web development work. 5 years ago , SOAP sucked and if you were using it or praising it you'd get laughed at because XML. Now REST sucks because GraphQL so let's go back to RPC like protocols and but with a twist , YAML or JSON ...

The good parts of WSDL, I presume? ;-) I spent way too long staring at raw WSDL, I almost think certain profiles are actually OK. But SOAP on the whole is a world of pain.

True REST shouldn't require a WSDL-like interface. The semantics of the graph it describes should be enough. This model, however, has yet to be fully realised; largely because of the large upfront cost in R&D. At my work, we are trying to develop in this area, but it's slow going.

Can you expand on that? I've got a mature API that's based around HATEOS, json-schema and HTTP content negotiation. It works really well, but client-side developers always need some time to get used to it, as they expect "REST" to mean "like Rails".

Our hope is that we can combine HATEOAS with an ontology to create autonomous clients and, otherwise, provide rich enough metadata in each resource to generate an appropriate UI (for human facing clients); the 'semantic web' approach.

Quite true, but the benefit of something like this is the ability for humans and machines to parse in one spot.

This can be both a spec and documentation at once. Client libraries can be generated and services can be stubbed.

Personally, I'd love to see something in reverse: traverse an existing restful service and produce a RAML document.

We're playing around with related ideas here [0]. It's understandably slow-going, because it's a hard problem to make a system 1) respond correctly to highly-specified custom queries, 2) easy to use and 3) scalable/performant.

[0] https://github.com/Mec-iS/mild-QL/issues/3

WSDL :-)

Reply on news.ycombinator.com