3 ms·
On the contrary; the lesson learned from those days is that codegens and declarative inputs to codegens (i.e. API specs) have their place, despite the particula
by niftich 9y ago
On the contrary; the lesson learned from those days is that codegens and declarative inputs to codegens (i.e. API specs) have their place, despite the particular stack falling out of fashion.
APIs that were put out when the "RESTful" movement was at its peak were documented solely in prose, a big regression from the WSDL days. OpenAPI (or a few years ago, Swagger and its contemporaries RAML and API Blueprint) attempt to retrofit what we've lost.
Spec-driven codegens allow shops that put out APIs to quickly bootstrap first-party clients, gaining an instant competitive advantage over similarly-positioned competitors who don't publish a first-party client.
- icebraining 9y agoSo why not keep using SOAP and WSDL?
- organsnyder 9y agoSOAP vs. REST is not simply XML+WSDL vs. JSON+OpenAPI. REST is resource-focused, where SOAP is operation-focused. REST takes advantage of HTTP's built-in features (verbs, caching, etc.) in ways that SOAP doesn't (SOAP is basically RPC tunneled over HTTP POSTs). I work on an API team that is in the early stages of switching from SOAP services to REST (using Swagger/OpenAPI). Shifting mindsets from RPC-based to resource-based APIs is challenging, but very beneficial (of course, there are still use-cases for RPC-style APIs).
- icebraining 9y agoAh, then I had a misconception of OpenAPI; my perception is that it was mostly used by people who wanted to use REST like how they used SOAP (using URLs and such but still fundamentally RPC). Does that mean OpenAPI lets you model and describe a real hypermedia application, following the REST constraints? Including ignoring the URLs and focusing on media representations and their relationships?