I have a question about the REST API and would be thankful if you could help me with it.
As we know, Django provides a template engine along with template tags to include python data types inside a HTML file to present the data to the user. The output will be an HTML file that is sent to the client through HTTP and the browser renders the HTML and presents the data to the user. Keeping this in mind, it is somewhat unclear to me why we actually need a REST API. Under what conditions do users prefer to receive a JSON file instead of a HTML file? I know that JSON files have some advantages over HTML, but what I don't understand is when it is needed.
The common cases for using DRF are:
You're creating a public-facing external API for third-party developers to access the data in your site, and you want to output JSON they can use in their apps rather than HTML.
You're doing mobile development and you want your mobile app to make GET/PUT/POST requests to a Django backend, and then have your backend output data (usually as JSON) to the mobile app. Since you don't want to pass back HTML to the mobile app, you use DRF to effectively create a REST API that your mobile app can call.
You're creating a web app, but you don't want to use the Django templating language. Instead you want to use the Django ORM but output everything as JSON and have your frontend created by a JavaScript MVC framework such as React, Backbone, AngularJS, etc. In those cases, you can use DRF to output JSON that the JavaScript framework can process.
Related
I want to develop my own single page web application (SPA) to get to grips with the modern and highly fluid world of web development. At the same time, I would like to use the page rendering technology (SSR) with built in data into html. However, there is an authorization problem.
Suppose that the user has already logged into the account before, as I imagine re-opening the site:
First request: the client makes a request to the frontend server along with identification and authorization data (for example, user id and token; the only option is to save them in cookies), the frontend server makes a request to the api server, transferring these service data, then the api server gives the information about the user and the content of the current page (in the same json), the frontend server renders this into a finished page and delivers it to the client.
Subsequent requests: the client directly addresses the api server, transferring the same (or updated after the first request) authorization data, receives json and processes it independently.
Actually, I want to move on to the question. Do I understand this interaction correctly? Can you do it differently / better? Are there tools that allow, for example, to use the components of the frontend framework as components of the MVC backend framework, so that one server does the rendering without unnecessary requests? Or a unified tool that includes the same coding for the frontend and backend to solve these problems? I will say right away that I would not like to write a backend in JS.
I can roughly imagine how you can get by with one request when using AngularJS (with a module for single page applications) and any backend MVC framework; although there will not be a full-fledged render, but search robots will not have to wait for my first fetch, since the data will be delivered initially, for example, through the data attribute. But in this case, I plan to choose Svelte (Sapper) and Ruby on Rails as the stack, although I think this is not important.
Thank you for your attention to the question!
Are there tools that allow, for example, to use the components of the frontend framework as components of the MVC backend framework, so that one server does the rendering without unnecessary requests?
If that's what you want you can install a frontend framework in Rails using webpacker. After that you will have a folder in your rails project that will contain your Svelte components. Then you import Svelte components in erb templates and pass data as props.
I have tried that approach but personally I prefer a separate frontend and backend talking through API calls. Then in your frontend you need something like Sapper if you need SSR. With webpacker you don't(assuming you mostly use Rails for routing).
If you are worried about authorization it's not really hard to implement. And after login you can store user info on local storage for instance for subsequent requests. But of course if you install with webpacker it's all done within Rails hence it's easier.
From my experience, using webpacker it's easy and quick in the beginning but you are more likely to get headaches in the future. With separate backend and frontend takes a bit more work, especially in the beginning, but it's smoother in the long run.
This helped me set the authentication between rails api and vue frontend.
So, if you wish to separate them, just install Rails as API only and I suggest you to use Jbuilder to build your jsons and serve them to the frontend as you need them.
I have managed to make run Laravel 5.4 and implemented the API Authentication (Passport).
What I would try to achieve is to make this as my API server and build React applications that would interact on this API.
Does this mean I have to make routes on routes\api.php?
Let's say I have a React app name requestform on development and running on http://127.0.0.1:8080. How will I consume an api route with axios or jquery?
I can't seem to make the correct keyword to search on google and all the samples I can get are the ones that the API and the javascript application is on the same domain.
This post may have been answered by now. But if not then...
I think you are in the right track..
Does this mean I have to make routes on routes\api.php?
Yes. Your API routes will depend on this file.
Let's say I have a React app name requestform on development and running on http://127.0.0.1:8080. How will I consume an api route with axios or jquery?
Make sure your API Server is running, say it's on http://server.dev, you can consume the API in another app by http://server.dev/api/[your-routes].
I can't seem to make the correct keyword to search on google and all the samples I can get are the ones that the API and the javascript application is on the same domain.
This is a matter of what front-end programming you know. You can use any javascript knowledge to consume your own API with the same domain. There is already a Vue integration packaged in Laravel 5.4+ or just plain vanilla javascript or jQuery.
I have a REST API developed using Django Rest Framework. I am wondering if I have to do string escaping of the data coming from a POST request (before it's stored in the database) or does DRF already do that for me?
I know that Django does some autoescaping, but not sure if it's the case for DRF as well.
Escaping user input is one good defense against XSS attacks. Typically it's done at the point of rendering, not at the point where the data is exposed. For example, in Django server side templates, it's done in the templates, not in the ORM. This allows developers to choose how to render data based on their needs (e.g. some data may be markdown).
Looking at a few client side frameworks, they all escape output by default, and force developers to explicitly declare when they want to render raw html:
React: SetDangerouslyHTML
Angular 2: [innerHTML]
Vue: v-html
I'd recommend not trying to force this into the API but into the consumers of the API.
I want to create a web app that uses Twitter Bootstrap for the front end, and the backend uses Spring+Hibernate.
Now, some data has to be stored in each user's session-- how do I store/manage such data?
Do I have to use a 3rd party JS framework like Angular (by Google) or some other framework for this purpose?
Also, in such a hybrid app, should I use the JS framework (like Jquery or Angular JS) for storing the data and then send it to the Spring + Hibernate API? What I mean is, I can as well store the object-> relational DB mapping in the js framework, and use Spring only for basic database inserts/updates/selects?
Twitter bootstrap is a CSS framework with some javascript plugins, and is not a language in itself. Using it or not using it will have no impact on what you can/can't use on your backend.
As for sessions; sessions should always be stored server-side... therefore using Bootstrap will have no affect on your implementation of sessions.
Finally, in regards to keeping any of your database logic client side in javascript, NEVER do this. Javascript code can extremely easily be modified by the user, so anything client side should be considered unsecure. Do not ever put anything unsecure in your database.
We can use Twitter Bootstrap for the front end, and Spring MVC -> REST API for the back end...
For simple apps, ex search-only apps we can straightaway create an API and use JQuery to connect to the API and fetch data.
For more complex apps, the problem is that REST APIs dont store session data... For this, however we can use Spring MVC-> REST API as that has support specifically to handle sessions.
Refer http://tedyoung.me/2011/10/19/practical-spring-mvc-part-5-sessions/ that explains how to store session data using Spring MVC- and the front end is a simple HTML/CSS web page.
I'm designing a web service that serves up JSON through a REST API. This API is currently being used by an iPhone app to do CRUD operations.
My question is, can I design a web client that uses this REST API using nothing more than ExtJS (or some other RIA framework) and HTML pages? In other words, can I create a static HTML page that uses ExtJS to send AJAX calls to the REST API and receive JSON data from it? Or is this thinking too naive and wrong?
I think this is perfectly acceptable as long as you know that your users browser will be able to handle javascript and AJAX accordingly.
Yes! YES! You can use static html and js files, served by any web server, to build an Ext JS application. Ext JS is very happy to talk REST and JSON to your web service.
Build your Ext JS application outside of ASP.NET MVC. You don't need it.