English is not my native language and i don't understand difference between query and request.
What is the difference between words and how to use them correctly on the web
Request means ask for something and it shall be given. You need that thing.
Query means ask whether or not something is true/ available or false/not available, you may not get that thing back but you'll get the status, state or info.
Request means ask to collect that object.
Query means ask to confirm the state of an object ex. Availability, true/false,
Can I have some food to eat? You are requesting for food.
Is that way good? This is a Query:
A request is like when I ask you to go to the supermarket. Here, I’m requesting you to leave your current place, go to the supermarket to bring one or many items and come back. Now, you can go to the supermarket but once you arrive you will ask yourself, what should I bring? In order to make your visit to the supermarket successful, I should give you a list of things that you need to bring or do at the supermarket, give you a description for the items and tell you in which aisle or department you can find them. This list now is representing your query.
So, if your client needs to fetch some data for example from a remote server, you will need to make a request. This request has a type, like ‘GET’ to fetch resources or data back, or ‘POST’ to do an operation like creating a new user account.
For the request to do its job, you have to specify what data or resources you need this request to fetch and where to find it. It’s like what items do you need to buy from the supermarket and from which aisle can you find them. For example, your request can have a query to return a specific user’s data based on his id. But you need to know to whom should you send the request with this query in order to get the user’s data back based on the passed id.
In order to make a request, you need to send it to your backend’s application that you can access using an IP or a domain mapped to it. Something like: “http://www.mywebsite.com”. But to fetch specific type of data, like the user’s data you need to tell your backend application what are you searching for. This is specified by something called the “path”. For example: “http://www.mywebsite.com/users”. The path here is the “/users” part. The query works when you submit to this domain with the path one or more query parameters, like the user’s id. So, you will make a GET request to “http://www.mywebsite.com/users/1234”, where “1234” here is representing the user’s id that you need to fetch its data. It’s like telling you to go to the supermarket named “mywebsite.com”, go to the “users” isle or department and grab the item with the id “1234”.
I hope that I managed to simplify the concepts a little bit for you.
Mohammed's answer above is great and very detailed. In summary:
First of all, query and request can both be nouns and verbs. E.g:
I requested a refund.
We received a request for a refund.
I queried the price.
We received a query about the price.
To request something is to ask for something, an object or a favour etc. A request is a polite demand. To query is to ask about something i.e. you are wanting information. A query is a question.
Also, QUERY is an inquiry(Query and inquiry are synonyms)
They are both requests but the difference is that the QUERY is a precise request. In informatics, if you need information about something you need to send a specific request with precise information.
"I queried information about user account Maxim Pavlov" = "I need to know about this website users. In particular, I need to know if there is any Maxim Pavlov registered on this site".
If you are Arabic, best translations in Arabic would be, request = طلب and query = إستعلام)
I thought about this question and I think the Ahmed's answer is misleading to say the least.
When web developers talk about request, they usually mean request done via HTTP. There are other protocols, but HTTP is certainly the most common. Request tend to be fourfold: get, post, put and delete. A request is almost always associated with an endpoint. A request is more than just ask for something. For instance, a put request is basically either add information or a file stored on a web server or update it. On the other hand, a query, in the language of a web developer, typically means some information he would like to extract from the database where a certain condition needs to be met.
I will give you an example. When building an API, you may have just two endpoints which are mapping to a post request and a get request. When you hit the endpoint associated with the get request, by design it will always return the "current time" which requires no query in a database. Meanwhile, when you hit the endpoint associated with the post request, by design it will always get the leap years between, say, 1900 and 2000 which are all stored in the database and requires a database query to fetch that information back to you.
The Abdullatif's answer is by and large correct though.
Related
I am currently learning full stack dev, and have made a simple application with React on the front end, and set up a very simple REST api on my express web server that handles certain routes.
For example api/users returns a list of users from my database and returns responses as JSON data. api/blogs can return a list of blogs in JSON with a get request, or post a blog with a post request.
Say in my application, a game, a user has value of gold which is stored in the DB with their username and other game info. In the game if they unlock something or 'win', their gold gets updated. I would assume I would have to make a PUT request to the api/users and edit their gold amount to the database. But I am dreadfully concern, couldnt they always just make a PUT request from the outside and increase their gold at will? What possible ways exist to authenticate this route only from the server or allowed? This part makes 0 sense to me
I have learned and been able to implement very basic user tokenization with JWT, and so only logged in users with a valid token can make a post of a blog for example. This is done by adding their token with bearer as a Authentication header in the request, which the server verifies.
What you describe sounds as if the Javascript code that runs on the frontend would decide that a user has earned 10 pieces of gold, say, and you then want to inform the backend about the decision in a secure manner. That will not work, for the reasons outlined in When doing a booking system, where would it be better to do? Back end or front end.
It highly depends on the nature of your game and its rules for earning gold how this could be implemented securely. For example, if you earn 10 pieces gold by solving a mathematical puzzle within 1 minute, it could work like this:
The backend comes up with a puzzle "What are the prime factors of 2758238235918?" and stores the expected answer together with the deadline in its database, e.g.
{"user": "oscar",
"puzzleID": "ab45ga4753",
"answer": [2, 3, 3, 11, 71, 7993, 24547],
"deadline": "2022-07-09T20:11:00+02:00"}
It sends the puzzle to the frontend with an HTML form that contains a hidden input field with the puzzleID and a visible input field answer.
The user submits the form with their answer in a POST request to the backend.
The backend looks up the answer from its database (based on the puzzleID in the POST request) and compares that to the answer from the POST request. It also checks whether the deadline has not yet passed.
If the answer was correct and in time, then the backend updates the gold in the user record.
So i have been struggling with this one question some time now:
How to handle details Page or deep linking on the Frontend.
So, say, we got a paged collection endpoint with user entities in it and a React App consuming the endpoint.
The flow would be, user authenticates, gets collections, clicks on an item and is either:
Redirected to a new Url say: webapp.com/users/userid
A modal opens with the user details.
Say we got a scenario were two people working with the webapp, Person 1 wants to share a link with Person 2. Person 2 should do some updates on a specific user, which is identified by the link.
The link should be something like : https://www.webapp.com/users/{slug or id}
With Option 2 this functionality is not mappable.
With Option 1 we got to expose the ids in the response to identify the resource, which may work, but we would still need to hardcode the url, as the findById method is not exported as a Uri Template.
So, my Solution would be to add a slug for the resources, implement a search method by the slug, and then get the user, if found, by its self-link.
Sounds like a good solution for me, but on the other hand, I would have to add an extra frontend id(the slug here) which would need to be also unique, to the database model.
So how do you guys handle a problem like this, or is there anybody using spring data rest in this way or in production mode where you have the handle situations like this?
Should mention that this isn’t a primary problem with spring data rest but rather with hateoas itself.
thanks in advance
Florian
You don't need to hardcode URL template. Spring data rest will generate links for each resource.
You can refer to it from front end by some format like: {your_user_object}._links.self.href
I want to make an app where people can text (sms) their name to sign a petition and then their name would be added to a list of signees on a website for the petition.
The sms messages would be handled by Twilio and then be processed by a Node.js app. I would like to use Angular on the front end.
Question: What would be the best way to store the names? Do I need something like MongoDB or would a database be overkill? I'd also like to verify that only one name per phone number is entered.
If you don't use a database you'll need to store it in memory. This will mean when you restart the server or it reboots you will lose your names.
So the short answer is yes you will need a database.
As for checking if there are duplicates there are many method with mongodb.
You can use a find query first to check that it does not exist already.
You could use upsert which will replace a previous one matching one.
However you can use any type of database that you wish.
I'd like to vote in favor of a relational database, probably it's a good fit for your kind of project.
Take in account that you can also store some interesting fields that comes with the Twilio request like country and state to list some.
You can take a look at this tutorial where not only you can get the SMS but reply to the user to have a smooth user experience in the process: https://www.twilio.com/docs/sms/tutorials/how-to-receive-and-reply-node-js
I have a webhook designed in Node.js for API.ai that interacts with multiple API's to gather information and give response to user.
Since, I am interacting with multiple API's the response time taken is more than 5 secs which is causing the API.ai request to timeout.
To overcome this, I am trying to implement caching into the node.js webhook which saves the response from API's until a certain amount of time. This will remove timeout until the max-age header time is reached.
Edit: What is the best node module that I can use to cache the API responses for subsequest requests.
Note: I am using request node module for http requests but it doesnt seem to provide a way to cache the response.
All of the answers given are reasonable for tackling the cache problem on the request side. But since you specified API.AI and Actions, you might also be able to, or need to, store information while the conversation is in progress. You can do this using an API.AI context.
It may even be that if you limit it to just one remote call for each response from the user, you might be able to fit it in the timeframe.
For example, if you were having a conversation about movie times and ticket ordering, the conversation may go something like:
User: "I want to see a movie."
[You use an API to lookup the nearest theater, store the theater's location in a context and reply] "Your nearest theater is the Mall Megaplex. Are you interested in one there?"
User: "Sure"
[You now already have the theater, so you query for what it is playing with another API call and store it in a context] "There are seven different movies playing, including Star Wars and Jaws. Do those sound interesting?"
User: "No"
[You already have the data in the context, so you don't need another call.] "How about Rocky or..."
In this way you're making the same number of calls (generally), but storing the user's results in the session as you go as opposed to collecting all the information for the user, or all the possible results, and then narrowing them.
Finally decided to use the below module:
https://www.npmjs.com/package/memory-cache
This served my scenario better. Might try using Redis soon when i get some time.
is there a way to grab instagram users based on a specific hashtag ?
I run contests based on re posting photos with specified hashtag then randomly pick a winner, i need a tool that can grab the usernames of those who reposted that photo and used that hashtag.
You can query instagram using the API. There are official clients for both python and ruby.
You didn't specify what language/platform you are using, so I'll give you the generic approach.
Query instagram using the Tag Recent Media endpoint.
In the response, you will receive a user object that has the user's username, id, profile url, and so on. This should be enough to do what you are describing.
As far as tools, there aren't great options to probably do things exactly how you want. If you just want a simple contest, you could use statigram, but it's not free.
If you roll your own solution, I highly recommend you also do the following:
Implement a rate limiting mechanism such as a task queue so you don't exceed your API calls (5000 per hour for most calls). Also useful for failures/network hicups, etc.
Have users authenticate so you can use OAuth to extend your API calls to 5000/per user/hour to get around #1.
Try the subscribe API if there won't be many items. You can subscribe to a specific tag as well, and you will get a change notification. At that point though you need to retrieve the actual media item(s), and this can cost a lot of API calls depending on how frequent and what volume these changes occur.
If your users don't have much photos/relatively small/known in advance, you can actually query the user's recent media instead and filter in your own code by hash tag.