Develop Reference

Is using a query string in POST request a bad practice?

There is a system that sends POST requests from frontend to backend. These POST requests do not use the body to pass the data to the server; instead, it uses query strings in the URL params.
These requests do not send files or JSON, only several string params.
W3C does not describe that situation https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
Is it a bad practice to use query strings for POST requests, and if there any negative consequences of using that from security or performance or architecture reasons?
Are there any conventions that define the usage of body or query strings for different types of requests?

Reminder: In 2014, RFC2616 was replaced by multiple RFCs (7230-7237).
Is using a query string in POST request a bad practice?
Not if you know what you are doing.
Mechanically, it is all fine: are we allowed to use POST with a target-uri that includes a query-part? Yes. Are we allowed to use POST with an empty request body? Yes. Are we allowed to do both of those things at the same time? Yes.
The hard part: will this POST request invalidate the correct representations from the cache?
Cache-invalidation happens when the server returns a non-error response to an unsafe request (POST is an unsafe request method). The representations that are invalidated are those that match the target-uri of the unsafe request.
GET /foo?a=b HTTP/2.0
POST /foo?a=b HTTP/2.0
Here, if the POST is successful, the representations cached after the successful GET request will be invalidated in the cache.
GET /foo HTTP/2.0
POST /foo?a=b HTTP/2.0
Here, the effective request-uri is not the same, which means that general purpose components won't invalidate the cached representations of /foo.

There's nothing wrong with using query parameters in a URL in a POST request, with or without a request body. If it makes semantic sense for your request, it's fine. The POST method in itself has a semantic meaning distinct from GET, it doesn't require a request body to be useful, and the URL is yet distinct from that again. A classic example might be:
POST /foo/bar?token=83q2fn2093c8jm203
I.e., passing some sort of token through the URL.
There's no general security problem here, since anyone who could intercept this POST request to read the URL could also read its body data; you'll hardly find an attacker in a position that allows them to read the URL but not the body. However, URLs are typically logged in server access logs and browser histories, while request bodies aren't; that may or may not be worth considering, depending on what information you're transporting in those parameters and who has access to those logs.

Using body in GET requests

I am developing a REST API for one of my projects.
I need to use GET requests. I don't seem to understand why using url query strings is superior to body.
There are some obvious differences between the two ways to request data - like being able to see the parameters in the url, or the fact that the requests can be saved in the brower's history.
But is there anything more to it?
Is it bad to request data with body?

There's nothing wrong with using a body. GET method does not have a body not because of some prejudice against the usage of body.
If you have a look at the HTTP protocol specification, you might have some insight:
"The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI."
In simpler words, GET method is created to retrieve some resource using only URI. In even simpler words - if you can get some resource using only URI - GET is a method you should use.
As a matter of fact, you can send body with GET request, but it will just be ignored (more information here: HTTP GET with request body)
If you need to pass a body for whatever reason you will need to use a different method. POST is a prominent example:
"The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line."
If you working on REST API's I would highly encourage to read HTTP specification https://www.rfc-editor.org/rfc/rfc2616

Is it bad to request data with body?
Yes, it is bad.
The problem is that, in HTTP, GET method is specifically defined to not to include a request body.
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. -- RFC 7231
What's going on here, largely, is that early versions of the HTTP specification had some ambiguities about the handling of message-bodies in requests. In effect, putting a message-body into a GET request was "undefined behavior".
The working group is strongly motivated to ensure that the standard remains backwards compatible.
Part of the point of REST is that we are all using a common standard, so that the general purpose tools (browsers, caches, reverse proxies, spiders...) work for everybody -- or more specifically for everybody that abides by the standard.
With regards to GET, including a message body doesn't make sense when you consider caching semantics. Caching semantics in HTTP are currently defined by RFC 7134, the high level summary is that the target-uri is the primary cache key; caches only need to understand the metadata in the HTTP request to do their job properly.
If we were to apply semantics to the body of a GET request, we'd also need to define, in a general way, how those semantics affect cache behavior.
For instance, if you imagine a query scenario (like GraphQL), the expected representations in the response depend on the information encoded into the request body. So now you need to start defining when two request bodies are "the same" - is white space significant? does the content encoding matter? what about if the body is zipped? and so on....
We don't have this kind of problem with unsafe requests (for example, POST), because standards compliant caches MUST write through requests that are unsafe. There's no need to explore the representation of the message-body of the request because there are no circumstances where the contents would change this requirement.
There have been attempts at creating a new standard for the HTTP method that is safe and includes a message body. It's probably doable; in the sense that we introduce a new method token, and declare the semantics to be safe (so that we can perform preemptive fetching, and repeat requests on an unreliable network) and perhaps that public caches cannot store the responses, but must instead forward each request to the origin server.
That said, people have been aware of the gap for a while, and the problem doesn't yet have a standardized solution - so there may be some difficult aspect to it that isn't obvious (in addition to the political problems of adoption vs inertia).

Cross domain request with JSON response

I am trying cross domain request from my js file.
First,I was trying JSONP but my target domain URL is not support it. It return plain JSON object.
I am authorize person to access my target domain URL. but i can not modify it as per JSONP response.
SO how can i get JSON response from my target domain URL?

Without modifying a bit the server side there is not much you can do. The general policy is to not to allow cross domain requests.
There are few things worth mentioning though:
Try changing the server side so it will support JSONP.
If the HTTP response contains Access-Control-Allow-Origin header then you can communicate with it with normal AJAX. This feature is supported in modern browsers only. Check this out for more info.
You can do the cross domain requests with Flash and/or WebSockets. However server does have to support them.

I have always done it with jsonp, by passing a callback b/c services return json, if call back is passed then it will wrap all json in callback else they will simple return json.
But in your case
You can look up with this article
http://www.webdevdoor.com/jquery/cross-domain-browser-json-ajax/

Don't know what type application you are developing. But in ASP.NET you can do it by using a proxy page
These links may be helpful:
http://www.codeproject.com/Articles/667611/ASP-NET-Proxy-Page-Used-for-Cross-Domain-Requests
http://encosia.com/use-asp-nets-httphandler-to-bridge-the-cross-domain-gap/
https://gist.github.com/jkresner/3982746

Is there any way to check is given link really exist?

For example there are lalalalaal.com that do NOT exist. Is there any way using JavaScript (possibly with jQuery) to check is given link really exist?

There has to be a server involved because of the Same Origin Policy — but it doesn't necessarily follow that it has to be your server. :-)
You can use a third-party service such as Yahoo to do the proxying for you as discussed here: "Using YQL as a proxy for cross-domain Ajax". That shows how to use jQuery to query YQL's JSON-P and JSON-P-X interfaces for another domain's content.
It's not complicated, from the article:
$.getJSON("http://query.yahooapis.com/v1/public/yql?"+
"q=select%20*%20from%20html%20where%20url%3D%22"+
encodeURIComponent(url)+
"%22&format=xml'&callback=?",
function(data){
if(data.results[0]){
container.html(data.results[0]);
} else {
var errormsg = '<p>Error: could not load the page.</p>';
container.html(errormsg);
}
}
);

There isn't, the response from another domain will always be null (the same origin policy applies here). You'd have to contact your own domain and have it check server-side if the site actually exists...but JavaScript alone can't do this.

No, there isn't.
In order to find out if a URL exists, you have to make a request to it and see if you get a response. The same origin policy prevents JavaScript, running in a browser under normal security conditions, from reading responses from different hosts.

I don't think you can, for security reasons (same domain policy).

Use AnyOrigin or the FOSS clone I made of it, WhateverOrigin.

Cross-domain website promotion

I'd like to offer a way to my users to promote my website, blog etc. on their website.
I can make a banner, logo whatever that they can embed to their site, but I'd like to offer dynamic content, like "the 5 newest entry's title from my blog".
The problem is the same origin policy. I know there is a solution (and I use it): they embed a simple div and a JavaScript file. The JS makes an XmlHttpRequest to my server and gets the data as JSONP, parses the data and inserts into the div.
But is it the only way? Isn't there a better way I could do this?
On the Internet there are tons of widget (or whatever, I don't know how they call...) that gain the data from another domain. How they do that?

A common theme of many of the solutions, instead, is getting JavaScript to call a proxy program (either on the client or the server) which, in turn, calls the web service for you.
The output can be written to the response stream and then is available, via the normal channels, such as the responseText and responseXML properties of XMLHttpRequest.
you can find more solution here :
http://developer.yahoo.com/javascript/howto-proxy.html
or here :
http://www.simple-talk.com/dotnet/asp.net/calling-cross-domain-web-services-in-ajax/

CORS is a different way than JSONP.
Plain AJAX. All your server has to do is to set a specific header: Access-Control-Allow-Origin
More here: http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/

If you go the JSONP route, you will implicitly ask your users to trust you, as they will give you full access to the resources of their page (content, cookies,...). If they know that they main complain.
While if you go the iframe route there is no problems.One famous example today of embeddable content by iframe is the Like button of facebook.
And making that server side with a proxy or other methods would be much more complex, as there are plenty of environments out there. I don't know other ways.

You can also set the HTTP Access-Control headers in the server side. This way you're basically controlling from the server side on whether the client who has fired the XMLHttpRequest is allowed to process the response. Any recent (and decent) webbrowser will take action accordingly.
Here's a PHP-targeted example how to set the headers accordingly.
header('Access-Control-Allow-Origin: *'); // Everone may process the response.
header('Access-Control-Max-Age: 604800'); // Client may cache this for one week.
header('Access-Control-Allow-Methods: GET, POST'); // Allowed request methods.
The key is Access-Control-Allow-Origin: *. This informs the client that requests originating from * (in fact, everywhere) is allowed to process the response. If you set it to for example Access-Control-Allow-Origin: http://example.com, then the webbrowser may only process the response when the initial page is been served from the mentioned domain.
See also:
MDC - HTTP Access Control