enter image description here
What this picture actually describes?
I have a confusion, which is, whenever we are sending a GET request to the server via a API,
are we sending it in JSON format ?Or, in HTML or any simple Text format?
On the other hand, whenever the API is sending a request (HTTP verb actually) to the server, is it using HTTP format? and the server also returns a response in HTTP format or in JSON format?
I know this question is very silly....but I am very new in API world.
The picture is not accurate, the server sends a response and the MIME type does not matter, it can be even RDF n-triples or images depending on the type of the service and what it supports. The protocol is always HTTP, though theoretically it is possible to use a different protocol. REST has some mandatory constraints, you can read about them in the Fielding dissertation or I wrote about them here and here.
Related
Background:
Looking at some links like these below, I noticed two unique sets of descriptions for GET versus POST.
One description states that the difference is in how the information is sent: GET sends that information through the URL whereas POST sends that information through the HTTP request body.
Another description states that the difference is in which way that
information is sent: GET sends information to the server whereas POST
requests information from the server.
I find these descriptions to be lacking for the following reasons:
What if I want to get something from the server (GET) but I am sending a large amount of data first (eg. 50MB of text) so I would need to send it in the HTTP request body (POST). Would it be OK to use POST to get something from the server?
What if I don't want sensitive information to be stored in the URL, is it OK to instead use POST everytime?
The jquery GET function has the same method signature as the jquery POST function (see documentation), specifically it can also send data as A plain object or string that is sent to the server with the request, which I interpret as being added to the HTTP request body. If data for GET can be sent via the HTTP request body, then to me, this contradicts most of these sites that claim that as one of the differentiating descriptions of POST vs GET.
Nothing's to stop me from creating API endpoints which are GET but behave like POST (or PUT, or DELETE or PATCH)
Question:
Is the lack of strict descriptions because of my poor understanding, because of the ad hoc development process for HTTP/Ajax or is it something else entirely?
Supporting Links:
HTTP Request Methods
GET vs. POST
GET vs POST: Key Difference between HTTP Methods
jQuery - AJAX get() and post() Methods
I am designing my first REST API.
Suppose I have a (SOAP) web service that takes MyData1 and returns MyData2.
It is a pure function with no side effects, for example:
MyData2 myData2 = transform(MyData myData);
transform() does not change the state of the server. My question is, what REST call do I use? MyData can be large, so I will need to put it in the body of the request, so POST seems required. However, POST seems to be used only to change the server state and not return anything, which transform() is not doing. So POST might not be correct? Is there a specific REST technique to use for pure functions that take and return something, or should I just use POST, unload the response body, and not worry about it?
I think POST is the way to go here, because of the sheer fact that you need to pass data in the body. The GET method is used when you need to retrieve information (in the form of an entity), identified by the Request-URI. In short, that means that when processing a GET request, a server is only required to examine the Request-URI and Host header field, and nothing else.
See the pertinent section of the HTTP specification for details.
It is okay to use POST
POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.”
It's not a great answer, but it's the right answer. The real issue here is that HTTP, which is a protocol for the transfer of documents over a network, isn't a great fit for document transformation.
If you imagine this idea on the web, how would it work? well, you'd click of a bunch of links to get to some web form, and that web form would allow you to specify the source data (including perhaps attaching a file), and then submitting the form would send everything to the server, and you'd get the transformed representation back as the response.
But - because of the payload, you would end up using POST, which means that general purpose components wouldn't have the data available to tell them that the request was safe.
You could look into the WebDav specifications to see if SEARCH or REPORT is a satisfactory fit -- every time I've looked into them for myself I've decided against using them (no, I don't want an HTTP file server).
I'm building a microservice which one of it's API's expects a file and some parameters which the API will process and return a response for.
I've searched and found some references, mostly pointing towards form-data (multipart), however they mostly refer to client to service and not service to service like in my case.
I'll be happy to know what is the best practice for this case for both the client (a service actually) and me.
I would also suggest to perform a POST request (multipart) to a service endpoint that can process/accept a byte stream wrapped into the provided HTML body(s). A PUT request may also work in some cases.
Your main concerns will consist in binding enough metadata to the request so that the remote service can correctly handle it. This include in particular the following headers:
Content-Type: to provide the MIME type of the data being transferred and enable its proper processing.
Content-Disposition: to provide additional information about the body part such as the file name.
I personally believe that a single request is enough (in contrast to #Evert suggestion) as it will result in less overhead overall and will keep things simple (and RESTful) by avoiding any linking (or state) between successive requests.
I would not wrap data in form-data, because it just adds to the total body size. You can just put the entire raw file in the body of a PUT or POST request.
If you also need to send meta-data, I would suggest 2 requests. If you absolutely can't do 2 requests, form-data might still be the best option and it does work server-to-server.
i've been researching/creating a REST api, in the backbone.js to php context.
i understand the concept of HTTP verbs and when they should be used
GET - select
POST - create
PUT - update
DELETE - delete
i also understand the concept of passing an identifier as a semantic url, e.g.
GET http://api/users/123
DELETE http://api/users/123
in these cases the "123" is the id the business logic will use to get/delete a user.
but what about the POST and PUT contexts? when sending a request to
PUT http://api/users/123
the api will update user id 123 with the supplied parameters, here's where my question arises.
i would assume the input parameters to update with would be sent as PUT parameters. in php syntax this is represented as: file_get_contents('php://input') (this is the same for delete requests.)
when testing this via backbone.js it works perfectly.
but when i try and create a new element with
POST http://api/users/
i would assume the input values would sent as POST parameters/ in php syntax this is represented as $_POST. but this does not work.
after some testing, and reading up on rails style REST apis (which is what the backbone docs suggest), i realized that all request variables are sent the same way. if i change my code to use file_get_contents('php://input') to get the request parameters for every request type, backbone works perfectly.
is this standard fair for REST apis? or just "rails flavored" ones?
PUT, POST, PATCH, etc (everything but GET and DELETE*) accept request bodies. Generally data is passed as either:
A URL encoded string of name/value pairs (exactly the same as a URL querystring) that is decoded and parsed by the server into $_POST (or similar depending on your web framework of choice). This typically relies on the presence of a Content-Type header set to application/x-www-form-urlencoded (browsers do this by default when forms are submitted). If you see the data in file_get_contents('php://input') but not $_POST it's very likely this header is not present or is set to another value. If you're using Chrome, you can see what headers and body the client is sending in the Network tab of the dev tools.
The other popular request body format is to use Content-Type: application/json and then write out a JSON string to the body. This can be accessed via file_get_contents('php://input') and then parsed with a JSON parser.
* Note on DELETE: it's a little unclear whether or not using a request body with DELETE is allowed or a good practice.
I have been writing iPhone applications for some time now, sending data to server, receiving data (via HTTP protocol), without thinking too much about it. Mostly I am theoretically familiar with process, but the part I am not so familiar is HTTP multipart request. I know its basic structure, but the core of it eludes me.
It seems that whenever I am sending something different than plain text (like photos, music), I have to use a multipart request. Can someone briefly explain to me why it is used and what are its advantages?
If I use it, why is it better way to send photos that way?
An HTTP multipart request is an HTTP request that HTTP clients construct to send files and data over to an HTTP Server. It is commonly used by browsers and HTTP clients to upload files to the server.
What it looks like
See Multipart Content-Type
See multipart/form-data
As the official specification says, "one or more different sets of data are combined in a single body". So when photos and music are handled as multipart messages as mentioned in the question, probably there is some plain text metadata associated as well, thus making the request containing different types of data (binary, text), which implies the usage of multipart.
I have found an excellent and relatively short explanation here.
A multipart request is a REST request containing several packed REST requests inside its entity.