4 ms·
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;
by Xophmeister 11y ago
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.
- cwp 11y agoCan 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".
- Xophmeister 11y agoOur 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.
- mikegirouard 11y agoQuite 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.
- andersriutta 11y agoWe'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 https://github.com/Mec-iS/mild-QL/issues/3