Is it a good idea to use already implemented Grape API endpoints from within your Rails Application controllers?
I'm making an application where my Rails Controllers have shared functionality with my API. I've already implemented the API of an application, now I'm implementing the controllers.
So my question is, is there a way to issue a request from a controller to my Grape API endpoint without it going through the internet? If so, is it a good idea or not?
Do not call Grape endpoints from your Rails controllers instead make Ajax calls to your Grape endpoints and consume the API from the web/mobile front end. It is a good idea to have a single point of entry to your application rather than exposing Grape routes as well as Rails routes.
Related
I have an existing RoR web application which currently uses Devise for authentication.
I am planning on adding API functionality in one manner or another for a mobile backend.
Would you recommend adding API functionality to the web application and using JWT, for example, to enable mobile authentication. Alternatively, would you have two separate applications, a web application and an API, sharing the same Postgres instance on Heroku?
I see pros and cons both ways, but it would seem to me that separating it into two applications would outweigh adding API functionality to the web app. Perhaps, it would make most sense to start over with just an API and add mobile app client and web application client functionality.
Creating a new API only backend might be easier at first, but you would have to copy all your app logic in the models over and keeping both sides up to date will be a pain. You can do it in the same rails app if you namespace the new API so that all calls are under a /api_v1 or something like that. Here is an article that show how you can have different versions of your API.
JWTs for authentication is a great way of doing it and Devise can support them by adding a gem like devise-jwt since adding a route and handling the creation and updating of tokens by yourself is a lot of work.
For the API itself you might want to consider using JSON:API with the jsonapi-rails gem or GraphQL with the graphql gem. This way when someone wants to use your API they can use an adapter for their framework that can talk to that kind of API and not have to worry about the structure of what it returns. There are adapters for both APIs that work with Andrioid, IOS, Ember, React, and all other major frontend frameworks.
I am building a rails website that must pass some routes through to other applications (written in ASP.Net Core). The rails website must serve some pages define as normal rails views/controllers, and some that come through from the other ASP.Net applications.
Authentication will only be handled at the Rails level.
This means that some rails controllers will call the other applications (which are not publicly accessible) by sending all post data through and send back their response directly without parsing or further looking at it.
What is the best way to accomplish this?
.Net 4.6.1
I am still very new to .Net and MVC. Trying my hand at creating an API and then what will really be a javascript app that will consume the API. I've got a thousand questions but I will focus on one area for this. In the API code I see the methods that support the CRUD operations. I will want the read-only API methods open to the world but the editing methods need authorization.
Is there a best practice here? Should I create two APIs? One for the "public" read actions and another for the admin operations? Can I keep one API and force the edit actions to require auth? I've seen a discussion of using API keys -- perhaps have API keys for the admin methods?
I would recommend reading these articles as a starting point (and some of the other articles in the same section!):
Authentication Filters in ASP.NET Web API 2
Authentication and Authorization in ASP.NET Web API
You can turn on or off authentication for web API at virtually any level.
Globally, per controller, or per action method.
You can also override something, so if you turn it on globally, you can turn it off for a particular controller or method.
So to answer part of your question, I can't see that there is a need to create two APIs, but the articles linked will help.
I am new with React and today I was working on react-routers. I am not clear which routes to use. My choices are Rails routing or React router. What are the difference between these?
React should be used for rendering and Rails should be used for the API.
Each react app should have its own server-rendered path, with calls to a rails API on the backend. The API should definitely be routed with rails, but only pass back the data you need to the react app. Rails 5 has ApiController you can use for your controller superclass.
TL;DR - React is frontend, rails API on the backend.
Also, you should really determine if you need something so heavyweight on the backend. Some lighter ruby alternatives are Sinatra and Padrino.
You can use them for both server side and client side. If you are fully MEAN stack then you can use that. If you are in Rails stack then it's not possible.
I've put together a RoR application and would now like to publish a RESTful web service for interacting with my application.
I'm not sure where to go exactly, I don't want to simply expose my ActiveRecord models since there is some data on each model that isn't needed or shouldn't be exposed via an API like this. I also don't want to create a SOAP solution.
My application is built using Rails 2.3.5 and I hope to move to Rails 3.0 soon after its released.
I'm basically looking for a way to map my ActiveRecord models to "models" that would be exposed via the web service. Is ActiveResource the correct thing to use? What about ActionWebService?
You can do that through a controller (or controllers). Your RESTful controller actions can define the API for incoming web service requests, and you can render XML or JSON in the response instead of rendering an HTML view.
I'm sure there are more sophisticated ways of doing this, but this is the simple approach.