I wrote some RAML recently and found it very good for creating a machine-readable representation of an API. We also wanted to make it human-readable and use it as our API reference (with the API console). I found it to be mostly good, but had some trouble when explaining larger concepts that span several requests. Also, it's harder to point to the "important" parts of the API if it's sufficiently large than it was wi…
RAML – RESTful API modeling language
31–40 of 59 posts
Re: RAML – RESTful API modeling language
#32Why not just call it an "HTTP API modeling language", since that's what it is, instead of using buzzwords for the sake of it?
Re: RAML – RESTful API modeling language
#33This completely misses the point of REST. By miles. Why not just call it an "HTTP API modeling language", since that's what it is, instead of using buzzwords for the sake of it?
Re: RAML – RESTful API modeling language
#34It's nice, but because of the HAML-like format, there are a lot of empty space characters included. That's great for readability, but it doesn't seem like a perfect choice for a webservice description language, since that content might get hosted and transferred often over the network for clients that might be interested in it. You could convert to binary to compress it, but that makes it harder for the client, so th…
If size is a concern, have your webserver gzip it. https://en.wikipedia.org/wiki/HTTP_compression
Re: RAML – RESTful API modeling language
#35Earlier quoted context omitted.
If size is a concern, have your webserver gzip it. https://en.wikipedia.org/wiki/HTTP_compression
You should probably have a format that is easily digestible, like WSDL was for SOAP services. Requiring the person serving the RAML to setup their webserver to gzip it and requiring the client to gunzip everything is not very friendly. Having a JSON version of the spec would condense it while still allowing it to be readable, and it would be easily digestible in Javascript and many other languages without an addition…
Re: RAML – RESTful API modeling language
#36Calling this a "RESTful API modeling language" is like calling a water cannon a flamethrower. If we're going to call this RESTful, we might as well call SOAP RESTful.
Re: RAML – RESTful API modeling language
#37Re: RAML – RESTful API modeling language
#38Earlier quoted context omitted.
If size is a concern, have your webserver gzip it. https://en.wikipedia.org/wiki/HTTP_compression
You should probably have a format that is easily digestible, like WSDL was for SOAP services. Requiring the person serving the RAML to setup their webserver to gzip it and requiring the client to gunzip everything is not very friendly. Having a JSON version of the spec would condense it while still allowing it to be readable, and it would be easily digestible in Javascript and many other languages without an addition…
Re: RAML – RESTful API modeling language
#39This completely misses the point of REST. By miles. Why not just call it an "HTTP API modeling language", since that's what it is, instead of using buzzwords for the sake of it?
How does this miss the point of REST?
There's nothing wrong with what the author is trying to do, but it's nothing to do with REST.
Re: RAML – RESTful API modeling language
#40I wrote some RAML recently and found it very good for creating a machine-readable representation of an API. We also wanted to make it human-readable and use it as our API reference (with the API console). I found it to be mostly good, but had some trouble when explaining larger concepts that span several requests. Also, it's harder to point to the "important" parts of the API if it's sufficiently large than it was wi…
Disclaimer: I work on making API Blueprint better.