I understand that people use something like "/api" to send data. but lets say I have a page that has a route ("/home") I could do DB stuff and send a res.send() with the data from the DB. Should I be making a call to the /api when the user visits the home page? Why would I need both? I see people talking about api routes but I'm not sure when to use it. I'm assuming we don't do res.render in an /api route. It is mostly to send JSON. I never use api route I usually use the /home way. Should I be using the api way?
I'm confused on when to use it
Edit I guess a use case for having both is returning data for outside users and to also returning data for your website. Do people combine both?
It is just about naming convention. /api is where people keep APIs for single pages apps or mobile apps. If you have neither of those, you can use /home or for that matter, any named route for your purpose. It is just a coding practice and nothing else.
Related
Question
I have a probably rather simple question, but I'm unable to find an answer with nice explanations:
What is the difference (if any) between a route and an endpoint in the context of a RESTful API developed within a Node.js / Express application (but these concepts may be broader?!)?
(Does it relate to URLs in some way?)
Example
For example, in this article: https://medium.com/#purposenigeria/build-a-restful-api-with-node-js-and-express-js-d7e59c7a3dfb we can read:
We imported express which we installed at the beginning of the course, app.get makes a get request to the server with the route/endpoint provided as the first parameter, the endpoint is meant to return all the todos in the database.
These concepts are used interchangeably, which makes me confused.
(please note that I'm a 100% beginner with REST API, nodejs and express but I try to do my best to learn).
Edit
The two first answers chronologically speaking make me even more confused as they are perfectly antagonistic.
3 different concepts here:
Resource: {id: 42, type: employee, company: 5}
Route: localhost:8080/employees/42
Endpoint: GET localhost:8080/employees/42
You can have different endpoints for the same route, such as DELETE localhost:8080/employees/42. So endpoints are basically actions.
Also you can access the same resource by different routes such as localhost:8080/companies/5/employees/42. So a route is a way to locate a resource.
Read more: Endpoint vs. route
Read more: Endpoint vs. resource
Route
URI path used to access the available endpoints.
example: http://www.mywebsite.com/
Endpoint
performs a specific action.
has one or more parameter(s).
returns back data.
example: GET http://www.mywebsite.com/Products
A Route is the URI, and the Endpoint is the action performed on the URI.
Routes and endpoints are associated concepts - you can't really have one without the other.
What is an endpoint?
Generally speaking, an "endpoint" is one end of a communication channel where one system interacts with another system. This term is also used similarly in networking.
For a typical web API, endpoints are URLs, and they are described in the API's documentation so programmers know how to use/consume them. For example, a particular web API may have this endpoint:
GET https://my-api.com/Library/Books
This would return a list of all books in the library.
What is a route?
A "route" is typically code that matches incoming request paths to resources. In other words, it defines the URL and what code will be executed. A route path might contain regular expressions, patterns, parameters, and involve validation. For example, consider this route path:
"{controller}/{action}/{id?}"
In ASP.NET, pattern matching is applied, so GET https://my-api.com/Library/Books/341 would call the Books public method on the Library class, passing a parameter of 341. Routing frameworks can be very flexible and versatile.
The simplest example of an endpoint is to put a file you want to be consumed (say data.json) inside the public_html folder of your web server. It can be reached by GET https://my-api.com/data.json. The routing is handled by the web server out of the box and no routing code is required.
Some good things to read next:
Express.js - Routing
Wordpress Developer Resources - Routes and Endpoints
When to use "client-side routing" or "server-side routing"?
Endpoints are basically use to perform specific task and return data and endpoints are kind of part of a route.
For example is route and this is also a route but here both of them are returning different data not he same so, we can say that the last two parameter here is kind of end point means the id and question string.
endpoints:
/56075017/difference-between-route-and-endpoint
/56040846/how-to-use-the-classweight-option-of-model-fit-in-tensorflow-js
route:
https://stackoverflow.com/questions/56075017/difference-between-route-and-endpoint
https://stackoverflow.com/questions/56040846/how-to-use-the-classweight-option-of-model-fit-in-tensorflow-js
In this example: http://example.com/my-website/comments/123:
Route:
my-website/comments/123
Endpoints: (a fancy word for a URL with an action)
GET http://example.com/my-website/comments/123. returns the comment data.
DELETE http://example.com/my-website/comments/123. deletes the comment and returns the now-deleted comment data.
I'm currently using express to handle client request. At one point I need to handle get request if user loads any page of my app. So, I want all the routes to be configured at some place.
For example:
"/about"
"/contact"
"/listing"
"/product"
Above there are multiple routes and for each route I need to write app.get('/about', handler)..like this. So rather then writing multiple get handlers I want to use these path dynamically.
Is there a best way which I can use to store all the route path at one place (not DB) and can read from there only. Currently I am thinking to use JSON where I will store all the path with method type, params etc.
Also please validate is this a correct approach to handle such things or any better way or any node module.
It's common practice to write different methods for each route.
This makes sense since you'll want to return something different for /about than for /contact.
To organise this in a scalable manner you should create different files for each route. You can look at this official Express.js example.
I am totally new to Action HeroJS and I was wondering how can I restricted users to access my action herojs rest API, url from the browser?
I have even put the route as POST, but it is still accessible by get method?
Just like in java when we specify a rest api as post, it will not be accessible by get or browser url?
How can I accomplish this?
Edit:
Contacted the Action Hero, on github, they were pretty helpful, the solution was:
in web.js, put simpleRouting : false, and it should resolve the Issue.
Before you could access a post routed action, from the URL but after doing this you cannot!!
accessing a POST using get will return you a 404.
Thanks #Evan
Regardless of your language/framework, all routes are able to be hit by anyone, unless you block them at load-balancer or similar level.
Rather than thinking about the problem as "how to block" access, you should be thinking about the problem like "how can I ensure that this user is authenticated to use this route". Using things like cookies or tokens is the way to go.
You can use actionhero's middleware to apply access rules to specific actions, and return errors to the use if they aren't allowed.
Here's an example project that does these types of things:
Actions for dealing with the session: https://github.com/evantahler/actionhero-angular-bootstrap-cors-csrf/blob/master/actions/session.js
Middleware which uses that session data for access: https://github.com/evantahler/actionhero-angular-bootstrap-cors-csrf/blob/master/initializers/session.js
and finally another action (route/url) which requires the logged-in-session middleware: https://github.com/evantahler/actionhero-angular-bootstrap-cors-csrf/blob/master/actions/showDocumentation.js
From what I understand, to use the browserHistory object in React Router properly, we need to use a wildcard * route so that the user is returned the single page application upon every refresh. Where this becomes a problem is when my client-side URL is the same as one of my api URLs.
For example, say I have a website called example.com and that one of the pages on this site is example.com/profile. If I refresh, the expected behavior is that it will simply reload the website example.com and route correctly to /profile, since the wildcard route should have returned the client the single page application. Where this doesn't work is if I have an API route /profile, i.e. example.com/profile. Now when the user refreshes the page, instead of being returned the the profile page, they are instead returned a JSON response from my API.
Depending on the order in which the wildcard route is declared, I can either have the API response returned on refresh, or the single page app on refresh, but not both when the API url is the same as the client side browser url.
Are there any suggestions around this issue? My current solution is to migrate all of my API routes to have /api/ prepended to them.
You need to make sure your client routes do not collide with your API routes, and prefixing API routes with /api is a pretty standard way to handle this.
There's no real way "around" the issue other than making sure they don't collide – various workarounds might be possible, but it's going to be more clear for everyone involved if routes are unambiguous.
I'm making a REST backend for private use of our frontend, they will both be in the same server.
The problem is that I'm worried about security issues, I don't want a attacker to use the API directly, either by JS or by using other REST client.
Lets take this service as an example
http://myserver:8080/something/webresources/film
That's a service that allows to GET, PUT, POST, DELETE I want that only the frontend be able to use it, otherwise since anyone can see client-code it would be easy to get the endpoint and start putting or getting data. I do have BASIC AUTH so they would have to register and if they did something wrong I would be able to see who did it, but that doesn't solve the problem.
I could implement access control so that a user only could get/update/delete their own movies, but I would have to do that for every REST service(I have over 100 by now), plus I might need to actually get others movies
This is my first public project, I am really lost.
You can do it through your web server. I'm using Nginx. I have an if statement that checks the $http_referer. If it returns nothing, or the value returned is not my application/frontend page (meaning someone is trying to hit the api directly), it'll return a 403 forbidden page.
If your application doesn't send out emails to your users don't worry about the following: I added a block to allow access to my static images as the only exception, as my application sends out emails with images and I don't want them to break.
That's it. Problem solved. No one has access to my api except my frontend page/application, unless they can forge the $http_referer to match my domain which if they can do that then they deserve to break in.
Your only option to call the REST API from server side. You cannot hide from the users what's going on in their browser... You can have a layered application, so the frontend layer can call the backend layer on the server while the client can see only the frontend. (Check the layered system constraint.)