11–18 of 18 posts
On a related note, http://editor.swagger.io & http://petstore.swagger.io provide a similar UI for exploring REST APIs which have an OpenAPI (formerly known as Swagger) specification.
When did the rename happen?
Things like postman ( https://chrome.google.com/webstore/detail/postman/fhbjgbifli... ) exist for normal REST APIs. But it's lack of use suggests to me this isn't something people need.
Things like postman ( https://chrome.google.com/webstore/detail/postman/fhbjgbifli... ) exist for normal REST APIs. But it's lack of use suggests to me this isn't something people need.
Interactively querying REST APIS is a massive pain, doing anything useful requires multiple dependent queries, postman doesn't really help with that. Being able to query a graph interactively is actually useful, I've used graphiql to explore the data graph to figure out the query I need for the data requirements of a component before I start writing the actual component itself.
That really depends on your API! We have an orchestration layer that exists specifically so our front end does not have to run multiple queries all the time. Most of what our front end does is by running a very small handful of queries.
I think orchestration layers are something most growing/larger orgs strive for, in my experience.
Am I the only one who designs endpoints to spit back usage instructions if you call them without arguments? This goes a long way toward helping devs use those endpoints, in my experience - and they can use normal tools (in particular, the network pane of Chrome Dev tools). This is not to take away from GraphiQL, but it doesn't seem like that much more than you get with such a convention.
This is distinct from throwing exceptions when an endpoint is called with e.g. invalid parameters.
Things like postman ( https://chrome.google.com/webstore/detail/postman/fhbjgbifli... ) exist for normal REST APIs. But it's lack of use suggests to me this isn't something people need.
"it's lack of use"
...?
Earlier quoted context omitted.
Interactively querying REST APIS is a massive pain, doing anything useful requires multiple dependent queries, postman doesn't really help with that. Being able to query a graph interactively is actually useful, I've used graphiql to explore the data graph to figure out the query I need for the data requirements of a component before I start writing the actual component itself.
> doing anything useful requires multiple dependent queries That really depends on your API! We have an orchestration layer that exists specifically so our front end does not have to run multiple queries all the time. Most of what our front end does is by running a very small handful of queries. I think orchestration layers are something most growing/larger orgs strive for, in my experience.
Earlier quoted context omitted.
> doing anything useful requires multiple dependent queries That really depends on your API! We have an orchestration layer that exists specifically so our front end does not have to run multiple queries all the time. Most of what our front end does is by running a very small handful of queries. I think orchestration layers are something most growing/larger orgs strive for, in my experience.
If it's actually a REST API then it's going to take multiple queries. Certainly you can put an non REST API in front of it to reduce the queries. Every site does it and every site does it in a different way. GraphQL is built to solve this exact problem in a standard way.
What even uses GraphQL, other than Facebook?
Things like postman ( https://chrome.google.com/webstore/detail/postman/fhbjgbifli... ) exist for normal REST APIs. But it's lack of use suggests to me this isn't something people need.
"1,407,161 users" "it's lack of use" ...?
I (wildy) assume a lot of people download it, but never use it. I'd be interested to see retention stats.