I am currently looking into adding Swagger to an API that I work on. I found rswag, but from what I can tell, I would have to manually write specs for every endpoint in my API. This API has hundreds of endpoints, so this isn't very feasible.
Django REST Framework has SchemaGenerator which can generate an OpenAPI schema, either as a static file to commit and edit as you see fit or a dynamic endpoint which can be consumed by Swagger UI. Is there any equivalent for Ruby on Rails?
As a side note, I am also using jsonapi-resources. I'd be open to tools that are specific to JSON API.
Related
The API is hosted outside the CMS and we have swagger JSON/YAML exported fro the API. Requirement is to publish only swagger documentation/spec in Bloomreach/Hippo cms.
Is there an inbuilt capability to directly import swagger json into Bloomreach/Hippo cms and publish the documentation?
I'm sorry you never got a timely answer here. AFAIK there is no ootb functionality for what you want. You can write code to perform this task, either as a service that polls your api or as a rest endpoint where the data can be pushed to. This will have to be translated to a cms document type.
I've been hearing a lot of developers raving about Graphql. After implementing in Ruby on Rails, I've begun to realize that it essentially does the same thing as JBuilder, which is built-in to Rails 5.
From a Rails perspective, what benefit does Graphql provide over JBuilder? Are they essentially used for the same thing? Is there something I'm missing in regards to Graphql?
One of the advantages of GraphQL is the fact, that it's a formally specified standard with its own query language.
It's safely-typed standard with its own specification. This means, you can interop with servers written in different tech stacks using the same query language and type system.
Since it's standardized, a few frontend js libs (Relay and Apollo) have taken advantage of that, making it very easy to cache and define tailored, client-scoped queries and mutations.
It exposes its own structure as so called Introspection API. This means that, you can document your API and query it using GraphQL itself - its self-descriptive. This gives a space for tooling support - example of such is GraphiQL, which allows to explore GraphQL schemas with ease. When using GraphQL, this feature is basically granted for free. You can see it in action i.e. in Github API Explorer, which also uses Ruby implementation of GraphQL AFAIK.
While most people think about it in terms of request/response, it also exposes publish/subscribe capabilities as GraphQL subscriptions via web sockets. Also within a standard.
How can I access the Appery.io (or any future db) that is exposed to the REST API using RoR?
So I have an app i built using Appery.io and I also created a test app using RoR that I would like to use to pull information from the Appery.io db and display it on my RoR app.
I am somewhat familiar with REST and get the idea of what it is doing but I am not to certain on how to connect or make a connection from my RoR app to my Appery.io app. Appery.io has the following documentation for their db api, Appery.io DB API .
I have been looking around and also have seen people mention the following gems for HTTP request:
Weary
HTTParty
RestClient
Would I use one of those? I also read about using Active Resource as a possible solution?
Any help with getting started or a tutorial or article to point me in the right direction would be very helpful.
Thanks!
You won't be establishing an ongoing connection, each request/response will be a single query to your Appery DB. You authenticate those calls using a custom header with API key as defined in the documentation. There's an example using cURL that might be a good place to start playing with the API before you pull it into your RoR app. That example shows you how to get your key, too.
It looks like you can use the predefined APIs, or you can define a custom REST API associated with your Appery app? Instructions for building an API appear to be here.
Once you get the calls working from cURL (or other web request client of your choice), adding the calls to the RoR app should be more straightforward. Any of those gems could probably ease that process: I've only used RestClient personally, but found it very straightforward.
Any of those call methods (cURL, other clients, the gems, etc) will allow you specify your URI, method (e.g. GET or POST), headers, request body (where appropriate), and will allow you to examine your response. Take a look at the gem documentation to see how those map exactly - it will vary slightly from tool to tool.
If you don't have prior experience with calling external APIs, and would like a conceptual explanation, I like this article as a (very short!) beginner's guide.
spray-swagger appears to be a good way to auto-generate documentation as well as client stubs for a REST API. Is there a way to automatically test these APIs using specs2?
I'm new to rails and am in the process of building my first app. The app in question needs to be built on top of an internally built API which is responsible for interfacing with our data layer.
Having read around on Stack Overflow and the web in general it seems as though Active Resource is a pretty neat tool for this however my question is whether it will work for the specific API I am consuming which is:
JSON output
Built in PHP and not Rails (although it is RESTful)
(point number 2 is the one I am most concerned about as, from what I have heard/read so far, Active Resource is primarily designed to consume API's from other Rails apps)
Thanks
JSON output - it will work. Default format is XML, but ActiveResource also supports JSON (PS: you will have to set format to :json somewhere in config).
API is built in PHP - as long as the response is in standardized format so ActiveResource can parse it, it doesn't really care whether the response was generated by Rails, PHP or monkey behind the typewriter :).
As you said, ActiveResource is used primarily as a way for several Rails applications to interact with each other, but it is also meant to be used in the way you intend to.