I'm in a situation where I need to execute a POST request only with path parameters and no content.
Since I'm using Spring Boot, I have a #PostMapping annotated method with something like this:
#PostMapping("/firstEntity/{firstEntityId}/secondEntity/{secondEntityId}")
I've read some topics and questions about sending a POST request without body, and found that sending a POST request without body, but with headers isn't a bad practice. It's just uncommon.
But, in that situation where I'm not sending anything nor at the content nor at the headers, is this a bad practice?
For those who are wondering why am I doing this, the fact is that I need to execute a method in my service layer that relates a record from one table with a record from another table.
GET requests can be bookmarked and hit from going to the url in the browser.
POST requests can't be bookmarked and can't be hit from going to the url in the browser.
You're correct in doing this through a POST because you don't want it to be bookmarked or accidentally hit
It is perfectly valid to have a POST with no body and in many circumstances it makes a lot of sense. An alternative would be:
POST /firstEntity/{firstEntityId}/secondEntity
and then supply secondEntityId as the body of that POST.
Related
I have a Node server that serves a HTML form. The HTML file submits a HTTP post request to the server, before the server extracts the information. Currently, the server assumes the post request comes from the form. If I was to make a request from Postman, with a different body, the server runs into issues as particular fields are not present.
I was about to add a server function that first parses the request's body, to make sure all fields exist before anything is done. This seems like a good idea to do anyway, but I was wondering if any other steps can be done first to validate the request, before the server parses the body as a secondary check.
My ideas: Have the HTML file add a particular header to the request, which is checked by the server. I know that someone could easily copy this, but I believe this would easily deal with bots making random requests. Any other ideas?
I've been reading a bit about post and get methods in http and I'm a bit confused
from the words themselves it sounds like GET is to get something/a resource from somewhere and POST is to send something somewhere
so I could do something like:
axios.get('https://jsonplaceholder.typicode.com/users) and I have received the list of users. that makes perfect sense
and I could do a POST request once a user has submitted my form to a database. easy
the bit that confuses me is when people say to use a POST instead of a GET. like how would I return the users from the url above using a POST? also the verbs sound weird if you are using POST to receive data??
also I read that GET requests can only take stuff over the url whereas POST has a response body. but in my example above with the users I got all the users in an array back to my app using GET and nothing changed in the url?
can someone help clarify this and explain how to use a POST when doing a GET
It really depends on the specific endpoint you are accessing. You shouldn't use a POST in lieu of a GET request if your goal is simply to read a list of users from the server. Also, if an endpoint is created as only accepting GET requests and you send a POST request then you will get a 405 "Method not allowed" in response. However, if the endpoint allows both POST and GET in order to read a list of users from the server then it depends on the use case for this POST method. The reasons can vary from security to specifying (in the body) the format in which you would like the data returned.
I would like to know why a developer would make a POST request without using a form.
Thanks!
To test the form for one. Then ajax requests can use post data. Also in php at leats you have curl wich I am pretty sure can make use of the post structure to communicate other distant pages.
Because GET and POST do not have the same semantic value. GET requests should be generally safe to perform at any time without compromising the system, while POST requests should be used when doing something important (like accepting a monetary transaction, or, in a less dramatic way, post a comment or something like that).
So it might make sense to make a POST request through AJAX if its result will affect a system.
Source: W3C HTTP/1.1 Method Definitions, read 9.1.1 Safe Methods, 9.3 GET and 9.5 POST. Don't be afraid, it's short and to the point.
Maybe to call a REST API, or other web services that require POST, or to upload a file to a server. You could use AJAX/JavaScript on client side, and just about any server side technology to mimic POST without a form.
POST is an HTTP verb. Browsers use HTTP as its data protocol for fetching HTML data and POST for sending the user submitted data. Basically, any data transfer over http could use POST.
Some of the examples are :
AJAX
REST
etc...
It seems common in the Rails community, at least, to respond to successful POST, PUT or DELETE requests by redirecting instead of returning success. For instance, if I PUT a legal change to my user profile, the idiomatic response would be a 302 Redirect to the profile page.
Isn't this wrong? Shouldn't we be returning 200 OK from the request? Or a 201 Created, in the case of a POST request? Either of those, in the HTTP/1.1 Status Definitions are allowed to (or required to) include a response, anyway.
I guess I'm wondering, before I go and "fix" my application, whether there is there a darn good reason why the community has gone the way of redirects instead of successful responses.
I'll assume, your use of the PUT verb notwithstanding, that you're talking about a web app that will be accessed primarily through the browser. In that case, the usual reason for following up a POST with a redirect is the post-redirect-get pattern, which avoids duplicate requests caused by a user refreshing or using the back and forward controls of their browser. It seems that in many instances this pattern is overloaded by redirecting not to a success page, but to the next most likely place the user would visit. I don't think either way you mention is necessarily wrong, but doing the redirect may be more user-friendly at the expense of not strictly adhering to the semantics of HTTP.
It's called the POST-Redirect-GET (PRG) pattern. This pattern will prevent clients from (accidently) re-executing non-idempotent requests when for example navigating forth and back in browser's history.
It's a good general web development practice which doesn't only apply on RoR. I'd just keep it as is.
In a perfect world, yes, probably. However HTTP clients and servers are a mess when it comes to standardization and don't always agree on proper protocol. Redirecting after a post helps avoid things like duplicate form submissions.
Is there any way to determine if a POST endpoint exists without actually sending a POST request?
For GET endpoints, it's not problem to check for 404s, but I'd like to check POST endpoints without triggering whatever action resides on the remote url.
Sending an OPTIONS request may work
It may not be implemented widely but the standard way to do this is via the OPTIONS verb.
WARNING: This should be idempotent but a non-compliant server may do very bad things
OPTIONS
Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.
More information here
This is not possible by definition.
The URL that you're posting to could be run by anything, and there is no requirement that the server behave consistently.
The best you could do is to send a GET and see what happens; however, this will result in both false positives and false negatives.
You could send a HEAD request, if the server you are calling support it - the response will typically be way smaller than a GET.
Does endpoint = script? It was a little confusing.
I would first point out, why would you be POSTing somewhere if it doesn't exist? It seems a little silly?
Anyway, if there is really some element of uncertainty with your POST URL, you can use cURL, then set the header option in the cURL response. I would suggest that if you do this that you save all validated POSTs if its likely that the POST url would be used again.
You can send your entire POST at the same time as doing the CURL then check to see if its errored out.
I think you probably answered this question yourself in your tags of your question with cURL.