The requirement is to implement a POST /v1/data and GET /v1/data API.
The upload API (POST) can have any Content-Type. This is not a problem as the content type is stored in database along with data.
The download API (GET) should:
set the same Content-Type as the last upload call and
validate with the Content-Type and the Accept headers received in the request.
The problem is in validating the Content-Type with the Accept header. The Accept header can be */*, text/* (partially concrete) or text/plain (completely concrete). If the last uploaded Content-Type is text/plain all the three above Accept headers are valid.
Is there a built in method such as bool validate(accept_header, content_type) which does the validation?
You can convert a String to a MediaType object with MediaType#valueOf:
Creates a new instance of MediaType by parsing the supplied string.
and check it with MediaType#isCompatible:
Check if this media type is compatible with another media type. E.g. image/* is compatible with image/jpeg, image/png, etc. Media type parameters are ignored. The function is commutative.
Related
I'm curious whether sending Content-Type: image/* in a HTTP response is correct. I know it's advisable to specify the exact MIME type but I'd like to hear if I can use such a header as a fallback when I know it's an image but I don't know its type.
I don't see any evidence that you can or should use wildcards in Content-Type.
RFC 7231 does allow wildcards like that in the Accept header, where you're indicating a range of acceptable content types. The definition of Content-Type does not give any special meaning to the * character, and image/* is not listed as a registered type.
If you cannot identify the media type accurately, you should just leave off the header entirely.
I am new to Postman. The Get queries work fine but I can't send Post.
I work with Net .Core.
In my controller I have:
[HttpPost]
public IActionResult Post(Order model)
{
return Ok();
}
I am getting error 400 if I am trying to add Content-Type manually or 415 if I leave it as is and just set JSON.
That's because your payload is sent as querystring instead of appliation/json.
The Params becomes querystring in the URL
I didn't see there's a green dot besides the Body. It's likely that you didn't specify a body. In other words, the Body is empty.
It seems that you want to send a payload of application/JSON to server. If that's the case, make sure:
Add a header of Content-Type: application/json in Headers
Add a well-formatted JSON payload in the Body Tab：
By the way,
A controller annotated with [ApiController] expects a payload of application/json by default, which means the clients need send a well-formatted JSON with header of application/json.
However, if you're using a plain controller instead of [ApiController], the body payload by default should be a form. In most cases they'll be application/x-www-form-urlencoded.
PostMan allows us to sends payload of different Content-Types. Please do check the related radio button when there's a need.
I have an aws API Gateway api to upload audio files to s3, sending x-amz-tagging key value pair in header , i get this in Method request headers of api , but the tags are not received at s3?
'x-amz-tagging': 'key1=value1&key2=value2'
postman is used to call the api , api call is successfully completed and the file uploaded to s3 but the x-amz-tagging in the method request header is not present in the tags in the s3
After some research i found a solution,
Choose Method Request in your method execution pane and choose HTTP Request Headers and you can Add Header, Here its x-amz-tagging
and also
Choose Integration Request and expand HTTP Headers and Add Header
here,
URL path parts, URL query string parameters, and HTTP headers sent from the client in the Method Request can be mapped by API Gateway to a HTTP header to be sent in the Integration Request:
Mapping value: A URL path part, URL query string parameter or HTTP header defined in the Method Request. These follow the naming convention method.request.{"path" | "querystring" | "header"}.{param_name}. Choose one of path, querystring or header depending on whether you're mapping from a URL path, URL query string or HTTP header respectively. param_name corresponds to the name explicitly given to the parameter in the Method Request set, i.e. the parameter needs to have been defined in the Method Request setup first. Alternatively, wrap a value in single quotes for static values. E.g. 'my_static_value'.
Name: The HTTP header name you would like the mapping value mapped to.
I want to get the request header before the webkitGTK begin to send request and load the page. Then I want to get the response headers. However, I don't find such API in webkitGTK.
In Webkit1 the signal you want is WebKitWebView::resource-request-starting: The request argument contains a WebKitNetworkRequest which has a SoupMessage which will allow you to modify the request headers. The same signal has resource argument which has a response-received which in turn will contain a WebKitNetworkResponse. The SoupMessage of that response will have the response headers you want.
In Webkit2GTK the WebKitWebView::resource-load-started should be useful for at least monitoring: request and resource arguments work almost like the WebKit1 versions. The bit that I'm not 100% sure about is whether you can modify the request headers here -- or if you have to implement a WebExtension and use the WebKitWebPage::send-request signal.
I'm making an ajax call to a rest API and specified the following header an http post request.
Content-Type application/json; charset=UTF-8
My post body contains some japanese/chinese characters.
Now what my question is, do I need the encode the body of the post request with UTF-8 encoding or the browser takes care of encoding?
When your Content-Type header declares UTF-8 charset, then you must send the content in the UTF-8 encoding.
Although browsers sometimes "guess" or "fix" the encoding, you should never rely on this, as this is a very fragile logic that often fails to work properly.
If your Chinese/Japanese content was in a different encoding (like Shift-JIS), then you will have to convert the text with library like iconv.
Alternatively you could declare that other encoding in the header, but note that you can use only single encoding for all of the response body. Converting everything to UTF-8 is usually the best solution.