request payload что это
Русские Блоги
О разнице между formData и Request Payload в HTTP
В http-запросах formData и request Payload часто появляются в POST-запросах, таких как обычные почтовые запросы ajax:
После отправки этого запроса его content-type: application/x-www-form-urlencoded И это параметр по умолчанию. По умолчанию для enctype формы формы также установлено это свойство. В нижней части заголовка запроса вы также можете увидеть отправленные параметры в FromData в.
Если мы изменим вышеуказанный код:
Кроме того, недавний новый запрос Fetch API также может сделать это.
на fetch В этой статье я не буду подробно останавливаться на этом. Вы можете прочитать еще одну статью о fetch. Здесь представлены некоторые введения в API, а также некоторые методы использования и демонстрационные тесты производительности.
Если честно, из приведенных выше примеров мы ясно видим, что параметры передачи появятся в formData По-прежнему request Payload Средний, зависит content-type 。
Заголовок объекта Content-Type используется для указания MIME-типа ресурса, медиа-типа.
В ответе заголовок Content-Type сообщает клиенту тип содержимого фактически возвращенного содержимого. Браузер будет выполнять поиск MIME при определенных обстоятельствах и не обязательно будет следовать значению этого заголовка;
Чтобы предотвратить это, вы можете установить для заголовка X-Content-Type-Options значение nosniff.
В запросе (например, POST или PUT) клиент сообщает серверу тип фактически отправленных данных.
на MIME Профессиональное объяснение таково:
MIME полное имя Multipurpose Internet Mail Extensions type 。
Это стандартизированный способ выражения характера и формата документов. Это определено и стандартизировано в IETF RFC 6838.
Агентство по присвоению номеров в Интернете (IANA) является официальным органом, отвечающим за отслеживание всех официальных типов MIME, последний полный список которых можно найти на странице типа носителя.
Браузеры часто используют типы MIME (а не расширения файлов) для определения того, как обрабатывать документы, поэтому важно, чтобы сервер был правильно настроен для добавления правильного типа MIME в заголовок объекта ответа.
MIME Независимый тип в основном охватывает наше ежедневное использование, как показано в следующей таблице:
Do you really understand form data and request payload?
As a small partner who has done front-end and back-end joint debugging, there may be some problems sometimes. For example, I clearly passed the data to the back end. Why does the back end say it didn’t receive it? At this time, there may be little partners in confusion, as we can see from the chrome dev tools (F12 debugger) in this article. FormData And RequestBody To provide a possible way of thinking. It also provides some inquiry methods for the children.
What is formdata? What is requestpayload? No explanation, directly above:
Difference?
Because here touched my knowledge blind spot, therefore had this article. The answer is that I’m here stackoverflow I got it. First of all, post questions and answers.
What’s the difference between “Request Payload” vs “Form Data” as seen in Chrome dev tools Network tab。
What’s the difference between request payload and form data in chrome developer tools?
The Request Payload – or to be more precise: payload body of a HTTP Request – is the data normally send by a POST or PUT Request. It’s the part after the headers and the CRLF of a HTTP Request.
A request with Content-Type: application/json may look like this:
If you submit this per AJAX the browser simply shows you what it is submitting as payload body. That’s all it can do because it has no idea where the data is coming from.
If you submit a HTML-Form with method=”POST” and Content-Type: application/x-www-form-urlencoded or Content-Type: multipart/form-data your request may look like this:
In this case the form-data is the request payload. Here the Browser knows more: it knows that bar is the value of the input-field foo of the submitted form. And that’s what it is showing to you.
So, they differ in the Content-Type but not in the way data is submitted. In both cases the data is in the message-body. And Chrome distinguishes how the data is presented to you in the Developer Tools.
It is translated as follows:
Request Payload More precisely Payload body of HTTP request 。 Generally used for data passing POST Request or PUT Request. It is HTTP In requestBlank lineThe back part of. (PS: here is a question that HTTP is often asked. What are the components of HTTP request? Generally, it is request line, request header, blank line and request body. Payload body should be the corresponding request body.)
A request is accompanied by a header set to Content-Type: application/json When, it might look like this:
If you normally request an Ajax. The browser will simply take your submitted content as payload Show it, that’s what it can do, because it doesn’t know where the data comes from.
There form-data Namely request payload 。 Here, the browser knows more: it knows that bar is the value of foo, the input field of the submission form. This is what it shows you.
So the difference is, they’re just Content-Type Different settings are not different in the way of data submission. Both submissions will place data in the message-body Medium. However, the developer tools of Chrome browser will distinguish the display mode according to the content type.
details
Well, here we know. In fact, it’s all in the payload. So what’s the difference? Why can’t the backend get value sometimes? So we have to say the parsing method of payload. Let’s take a look at this logic with a few test cases under chrome.
Traditional form form submission
Scene construction
If I click the submit button here, it will trigger the submission function of the browser. What is the result?
Attention points
Can see Content-Type by application/x-www-form-urlencoded 。
The form of value is key1=value1&key2=value2 Submitted in the form of.
Traditional Ajax submission
Scene construction
First we construct a simple function and then trigger it. From chrome feedback:
Attention points
1. default Content-Type by text/plain 。
2. Request payload will do string conversion for non strings.
3. pass xhr.send(JSON.stringify(obj)); Content to be sent can be corrected
Submit by Axios
Scene construction
Since Axios is already the quasi standard configuration request mode of Vue and react, let’s explore it here.
First of all, let’s look at the documents of Axios. What kind of parameters can be passed when the post is submitted?
Notice this type. We construct two scenarios. Correspond to it.
Pass string and object respectively, submit post request, and observe the result:
Scenario 1 – results when passing strings:
Scenario 2 – transfer the result of the object:
Attention points
1. When we pass a string, Content-Type Automatically turn to xxx-form-xxx The form. When it is an object, it is automatically converted to xxx/json 。
2. When string key1=val1&key2=val2 In the form ofJSON stringForm.
summary
After exploring so many situations, let’s review:
Content type differences
1. In traditional Ajax requests, Content-Type The default is text.
2. When the traditional form is submitted, Content-Type The default is “form” type.
3. When Axios passes a string, Content-Type The default is “form” type.
4. When Axios passes objects, Content-Type Default to JSON type
The value of content type, the difference of payload between form and non form.
1. Only string type is supported (several situations explored above)
2. The format of form to be passed is key1=value1&key2=value2 Similar GET Requested QueryString format
3. Non form is generally JSON.stringify(formDataObject) form
Back end can’t get value?
No matter what form is passed, when the backend parses the form information, it will consider Content-Type 。 If it is a JSON string, when the backend parses the content of payload, it must parse JSON. If it is key1=value1&key2=value2 Form, you need to split the string.
Of course, the framework used by the backend will deal with these things. However, the value interface provided by the framework to the backend may be different. Therefore, when dealing with requests, the front-end partners must consult with the back-end partners. JSON still FormData Ha.
Epilogue
Originally, it was just a small problem. After careful study, we found many details. I’ll take the time to sort it out today. I hope I can give you some help. It’s not easy to code, if you feel this article is useful to you. Like it, take it.
What’s the difference between «Request Payload» vs «Form Data» as seen in Chrome dev tools Network tab
I have an old web application I have to support (which I did not write).
When I fill out a form and submit then check the «Network» tab in Chrome I see «Request Payload» where I would normally see «Form Data». What is the difference between the two and when would one be sent instead of the other?
Googled this, but didn’t really find any info explaining this (just people trying to get javascript apps to send «Form Data» instead of «Request Payload».
3 Answers 3
A request with Content-Type: application/json may look like this:
If you submit this per AJAX the browser simply shows you what it is submitting as payload body. That’s all it can do because it has no idea where the data is coming from.
If you submit a HTML-Form with method=»POST» and Content-Type: application/x-www-form-urlencoded or Content-Type: multipart/form-data your request may look like this:
In this case the form-data is the request payload. Here the Browser knows more: it knows that bar is the value of the input-field foo of the submitted form. And that’s what it is showing to you.
So, they differ in the Content-Type but not in the way data is submitted. In both cases the data is in the message-body. And Chrome distinguishes how the data is presented to you in the Developer Tools.
What is a Payload in API?
What is a payload in API?
APIs have proven to be some of the best tools and protocols for permitting interaction, communication, and sharing of data between various applications and web services. And while understanding how the interaction and communication occur may be an uphill task, the other daunting task is to familiarize yourself with the endless list of terms associated with APIs.
While you may think that you understand everything about APIs, you’ll always come to discover that there is a new term that you didn’t know it existed. For instance, if you deal with API, you might have stumbled upon the term Payload being used on several occasions. But the bugging question is, do you what it is all about? In this article, we’ll try to uncover the meaning of the term payload and provide a few examples to help you understand what it entails.
What is a Payload?
In computer programming, various apps and systems share data and information regularly over the internet. When each unit of data is transmitted, it boasts two essential parts: the header/overhead identifier and the actual information dubbed payload.
The overhead/ header data is used as an identifier, and its sole purpose is to indicate the source and destination of the information being transmitted. This section of the data is striped off once the message reaches its destination. On the other hand, the payload refers to an integral part of each unit of data being transmitted. It is part of the unit data that carries the real message that an app or system needs for it to act.
Simply put, the term payload is utilized by programmers to differentiate between the essential information in a chunk of data and the information that is used to support it. The term originated from the transportation sector, where it refers to the load that a person pays for when they transport something.
Let’s, for example, consider a truck is carrying 15 tons of cement. When it passes through the weighbridge, it weighs more than 15 tons, taking into account the vehicle’s weight, the driver, and all the other things. However, although it transports all these things, the only item that the customer pays for is cement, hence the payload.
A payload in API is the actual data pack that is sent with the GET method in HTTP. It is the crucial information that you submit to the server when you are making an API request. The payload can be sent or received in various formats, including JSON. Usually, the payload is denoted using the “<>” in a query string.
Example of Payloads
In programming and software development, the payload is used in the context of message protocol to differentiate between the assisting and actual data in a query string. For instance, Let’s consider this JSON web service response.
In the above example, the payload is the Welcome, World! Since it is the part of the query string that the user is interested in. The rest of the information is referred to as the overhead data. This is because it is only used to show the source or destination and display authenticity.
API Payload Formats
Basically, you’ll find three payload formats:
API Request Payload Format
This request must have two parameters and a subelement:
API OK Response Payload Format
These features one parameter and one subelement:
API FAILED Response Payload Format
This also contains one parameter and one subelement:
Conclusion
If you didn’t know what a payload is, this article has provided you with an in-depth understanding of what it’s and how important it’s to the API world. Generally, the payload is the part of a query string that carries the essential message or information required by the server to generate a response or the user to make a decision.
For Enterprises
Bring software to market more rapidly with a dedicated API marketplace:
GET HTTP request payload
I am designing an API and I wonder if it is fine to send a JSON payload on a GET request?
In this other question Payloads of HTTP Request Methods, we can find according to this link:
Does this mean that I should not send a GET request with a payload? Are there risks to do so?
I found out that ElasticSearch was using such a payload on a GET request:
So if this popular libary does it and nobody complains, then perhaps I can do the same?
By the way, I would like to know if this is OK to mix queryString parameters and JSON payload? Exactly like this ElasticSearch query does. If so, are there rules so that we know which arguments should be queryString parameters, or payload parameters?
Roy Fielding’s comment about including a body with a GET request.
Yes. In other words, any HTTP request message is allowed to contain a message body, and thus must parse messages with that in mind. Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request. The requirements on parsing are separate from the requirements on method semantics.
So, yes, you can send a body with GET, and no, it is never useful to do so.
This is part of the layered design of HTTP/1.1 that will become clear again once the spec is partitioned (work in progress).
Then I don’t really understand why it is never useful, because it makes sense in my opinion to send complex queries to the server that wouldn’t fit well on queryParam or matrixParam. I think ElasticSearch API designers think the same.
I am planning to design an API which can be called like that:
Does it seem fine to you? Based on the above considerations.
4 Answers 4
Having the GET response vary based on the request body will break caching. Don’t go there.
The gist is: Yes you can, but you probably shouldn’t for various reasons, including:
Google App Engine, a popular web framework, uses a special url fetch library, which does not support making HTTP GET requests with a payload. Accordingly, if you want your API to reach Google App Engine users, then I would not recommend requiring this behavior.
The answers from speedplane and Julian Reschke give two concrete examples of things that will break if you rely on GET requests with a body/payload. You can write your app differently to everyone else, if you want, but the web is one area where standards should perhaps be taken even more seriously than normal. I know it’s tempting to be a trailblazer, but with all due respect, consider just how many websites exist, and how many web programmers there are building and maintaining them. If there was a definitively better way, you’d most likely see it widely used in production by now.
Standards change/are adopted slowly because so many people have to agree on them for them to work. You’re correct in saying that there are applications that break the rules, but you’ll notice they’ve caused headaches for people, and workarounds/redundancy measures are required in certain cases, as mentioned by Aetherus in their comment on another answer. I tend to take the path of least resistance on issues like this. If you really want to do it, I’m sure you can make it work, though.