As usual, we surf the internet using http protocol with firefox,chrome browser,such as we visit stackoverlow by https://stackoverflow.com/questions/ask, we get the rendered page, stackoverflow is process A, and our browser is process B.is this the RPC call?
RPC means giving the illusion of calling a procedure (method) whose implementation is in a process distinct from the caller. HTTP itself does not provide that illusion. The typical case of a browser requesting HTML from a server is not an RPC call.
However, RPC technologies can be built atop HTTP, where a remote method invocation is implemented as an HTTP request, and returning the method's results is implemented via the HTTP response.
Your example describes not a RPC call it describes a REST call.
The URI https://stackoverflow.com/questions/ask (unfortunately the name of the resource was not a good choice) is the resource (not a process) and through a HTTP method your are manipulate or request the resource. So REST is all about resources whereas RPC is about operations/procedures/methods.
A RPC call is also possible with HTTP. Always when you are using a HTTP to call an operation it's RPC. This is called
WYGOPIAO: What You GET Or POST Is An Operation
JSON-RPC uses The HTTP methods GET or POST to call an method/operation/procedure by sending an JSON encoded string. The example below shows the JSON-RPC object to call the method echo.
{"jsonrpc": "2.0", "method": "echo", "params": ["hello world"], "id": 0}
Related
I have read many discussions on this, such as the fact the PUT is idempotent and POST is not, etc. However, doesn't this ultimately depend on how the server is implemented? A developer can always build the backend server such that the PUT request is not idempotent and creates multiple records for multiple requests. A developer can also build an endpoint for a PUT request such that it acts like a DELETE request and deletes a record in the database.
So my question is, considering that we don't take into account any server side code, is there any real difference between the HTTP methods? For example, GET and POST have real differences in that you can't send a body using a GET request, but you can send a body using a POST request. Also, from my understanding, GET requests are usually cached by default in most browsers.
Are HTTP request methods anything more than just a logical structure (semantics) so that as developers we can "expect" a certain behavior based on the type of HTTP request we send?
You are right that most of the differences are on the semantic level, and if your components decide to assign other semantics, this will work as well. Unless there are components involved that you do not control (libraries, proxies, load balancers, etc).
For instance, some component might take advantage of the fact that PUT it idempotent and thus can re retried, while POST is not.
The Hypertext Transfer Protocol (HTTP) is designed to enable communications between clients and servers.
HTTP works as a request-response protocol between a client and server.
A web browser may be the client, and an application on a computer that hosts a web site may be the server.
Example: A client (browser) submits an HTTP request to the server; then the server returns a response to the client. The response contains status information about the request and may also contain the requested content.
HTTP Methods
GET
POST
PUT
HEAD
DELETE
PATCH
OPTIONS
The GET Method
GET is used to request data from a specified resource.
GET is one of the most common HTTP methods.
Note that the query string (name/value pairs) is sent in the URL of a GET request.
The POST Method
POST is used to send data to a server to create/update a resource.
The data sent to the server with POST is stored in the request body of the HTTP request.
POST is one of the most common HTTP methods.
The PUT Method
PUT is used to send data to a server to create/update a resource.
The difference between POST and PUT is that PUT requests are idempotent. That is, calling the same PUT request multiple times will always produce the same result. In contrast, calling a POST request repeatedly have side effects of creating the same resource multiple times.
The HEAD Method
HEAD is almost identical to GET, but without the response body.
In other words, if GET /users returns a list of users, then HEAD /users will make the same request but will not return the list of users.
HEAD requests are useful for checking what a GET request will return before actually making a GET request - like before downloading a large file or response body.
The DELETE Method
The DELETE method deletes the specified resource.
The OPTIONS Method
The OPTIONS method describes the communication options for the target resource.
src. w3schools
I have seen people use NewRequest() method of the "net/http" package for testing APIs. Why not use the NewRequest() method from "net/http/httptesting"? What's the difference? Documentation advises the following:
// To generate a client HTTP request instead of a server request, see
// the NewRequest function in the net/http package.
What would be the difference in handling cookies, for example? Both seem to be very similar.
TL;DR: they're the same type, used a bit differently for two use cases and initialized differently to serve these use cases
The difference is only in usage - they are the same type http.Request. http.NewRequest is used for the more "production" use case which is client - "create a new request to send to the server". When writing HTTP servers, it's occasionally useful to create requests for testing, which is what httptest.NewRequest does. The doc of http.NewRequest is helpful here:
NewRequest returns a Request suitable for use with Client.Do or
Transport.RoundTrip. To create a request for use with testing a Server
Handler, either use the NewRequest function in the net/http/httptest
package, use ReadRequest, or manually update the Request fields. See
the Request type's documentation for the difference between inbound
and outbound request fields.
If you check the docs of the http.Request type, you'll find things like:
// URL specifies either the URI being requested (for server
// requests) or the URL to access (for client requests).
//
// For server requests, the URL is parsed from the URI
// supplied on the Request-Line as stored in RequestURI. For
// most requests, fields other than Path and RawQuery will be
// empty. (See RFC 7230, Section 5.3)
//
// For client requests, the URL's Host specifies the server to
// connect to, while the Request's Host field optionally
// specifies the Host header value to send in the HTTP
// request.
URL *url.URL
Note the "For client requests" vs. "For server requests".
If you see a place that doesn't use httptest.NewRequest it could be because:
They're not aware of it
Or they need more careful fine-tuning that http.NewRequest doesn't provide
We know the difference between POST and GET, but why should a client state the method type when issuing http requests? Why should it make a difference for the server? in the end, it is the server job to deal with those requests according to their URL and Content. either by redirecting, blocking or accepting and using data (existing in the URL or request body).
An endpoint can accept both GET and POST requests (along with PUT, PATCH and DELETE). If the client does not explicitly state what type of request they are sending, the server will interpret it as a GET request (the default).
Consider the following PHP example, sitting on https://api.example.com/resources/:
<?php
if ($_POST["request"]) {
// Create new resource
}
else if ($_GET["request"]) {
// List existing resources
}
In both instances, the request parameter is sent to the same page, and different logic is run based on what the method is. But considering the same data is sent to the same page in both instances, the server wouldn't know which one of the two conditions to step into if the client doesn't explicitly specify the method.
In RESTful programming, both the client and server have been programmed to understand the request, but the client has no knowledge of the server itself. It is up to the server to process the request, based off of what the client asks it to do. And the client asks it to do different things by specifying the method.
I have proprietary http based API to test from JMeter. Unfortunately some of the endpoints of the API are expecting http DELETE method with a request body (I know its questionable API design to use DELETE with request body, but I have no ability to change that API and need to test it).
How can I test it from JMeter? It seems that standard HttpRequest sampler silently ignores my body payload without any warnings. (When I try it in POSTMAN its sending a request body for DELETE method)
I did find an old JMeter plugin called HTTP Raw Request that somewhat helps but still doesn't auto-calculate "Content-Length:" http header for my body payload...so I have to do it manually for every test case - which is a pain for dynamically generated data payloads.
So my question still remains: How can I test HTTP DELETE with request body from JMeter?
Here is the screenshot:
NOTE1: Starting from jMeter ver. 3.1 (see bugzilla #60358) it was fixed for Http GET request to be able to send body in the request...but DELETE was not added.
NOTE2: See bugzilla #61443 for the DELETE request with body.
NOTE3: I'm using client implementation called "Java".
As per reference docs:
http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Request
There are 2 implementations for http request sampler. The non default one called "Java" has this issue with not passing DELETE request body.
Luckily the default implementation called "HttpClient4" that correctly passes request payload for DELETE operation as per JMeter data entry screen.
To change implementations for http request sampler you have to go to "advanced" tab of the HTTP Request Sampler and select client implementation "HttpClient4" instead of "Java". Here is the screenshot:
After that when executed it correctly sends request payload for DELETE operation. Here is the screenshot:
I am new to servelts programming. and Just today, I started learning it. and I am a little bit confused concerning
HttpServletRequest. it is written in a tutorial that, the class doGET() has some methods such as form "query" data, HTTP request headers, and the client’s hostname.
As far as I understood, the HttpServletRequest is something like a protocol allows the SERVER to
receive a request from the CLIENT side. My question is, Why the CLIENT side is interesting in
knowing something like the client’s host-name or HTTP request headers.
If you found the question is silly please do not vote my question down, because I do not want to lose this account with stack overflow.
First of all HttpServletRequest is an interface implemented by your Servlet Container.
HttpServlet is a convenience class which your Servlet can extend from and get hold of all the HTTP specific methods. doGet() is one such method to process the GET requests.
HttpServletRequest is something like a protocol allows the SERVER to receive a request from the CLIENT side
HTTP is a request-response protocol. Your container forms a HttpServletRequest object from the actual request received by the Web Server and forwards it to your Servlet's service() method.
Why the CLIENT side is interesting in
knowing something like the client’s host-name or HTTP request headers.
If you are talking about Servlets, it is always executed in server side . Hence, methods like request.getHeader() is used by the Servlet to read headers from the request sent by the client. These headers provide some extra information about the request (or response).Many of the headers associated with a request are handled by the server itself. Take, for example, how a server restricts access to its documents. The server uses HTTP headers, and servlets need not know the details. When a server receives a request for a restricted page, it checks that the request includes an appropriate Authorization header that contains a valid username and a password. If it doesn't, the server itself issues a response containing a WWW-Authenticate header, to tell the browser its access to a resource was denied. When the client sends a request that includes the proper Authorization header, the server grants the access and gives any servlet invoked access to the user's name via the getRemoteUser() call.
Read HTTP Made Really Easy, An Overview of Request Headers.