I am working on wordpress REST API and I need to get all the posts available. And I need to know how many pages are available based on number of posts per page.
Based on this link, I can retrieve those info from X-WP-TotalPages and X-WP-Total response headers.
The X-WP-TotalPages and X-WP-Total response headers are extremely useful when creating pagination using the WP REST API as they list the total number of pages and the total number of posts respectively.
But when I execute a GET requests, no headers response are available. I can retrieve the other response though like the posts.
How do I return response headers in livecode?
Headers I set:
put "Content-Type: application/json" & cr after tHeader
put "Cache-Control: no-cache" & cr after tHeader
set the httpheaders to tHeader
Related
For example, I am sending a POST request(http://localhost:5600/api/Abc) using postman, now after completion of this, some response I will get in the body of response, this response mainly contain all the values of the newly added row. So if in the response body, I don't want all the value of this row, instead I want status code like 200 or 500 or 404 or anything. how can I achieve this?
I'm trying to figure out how to work with a REST api call that is paginated. The JSON response from each page of pagination has a flag "lastPage": True or "lastPage": False to specify if you've reached the last page.
In the Data Factory REST Connector article, the pagination section mentions several supported pagination schemes:
Absolute or relative path of next page in response body or header
Query parameter for the next page in response body or header
Header value for next page in response body or header
None of these three approaches seem to describe the type of response I'm dealing with. What solution would work in this case?
Here's the documentation for the API I'm working with.
About your request, it's not supported for now.
You could post the feedback here: https://feedback.azure.com/forums/270578-data-factory
We can help you vote it up to make product team know.
I'm using tRestClient to pull data from a REST API which returns data in pages of up to 200 items each. The link to the next page is provided in the response header.
How do I access the response header using tRestClient?
From what I can see, the only data returned is located in the body of the response.
Note: the same call from Postman verifies the existence of a response header labeled "Link" which contains the necessary data.
I found the answer in a post in the Talend Community
The response headers are stored in a global variable which is only actually populated when the response body is passed over to something such as a tLogRow (even if there isn't any content in the response body).
The global variable can be accessed via:
((java.util.Map<String,java.util.List<String>>)globalMap.get("tRESTClient_1_HEADERS")).get("NAME_OF_HEADER_FIELD_HERE").get(INDEX_HERE).toString();
where "NAME_OF_HEADER_FIELD_HERE" is the key (string) of the specific header you are interested in and "INDEX_HERE" is the integer index (0-based) of a specific value in the list of values associated with that particular header.
In this case we are explicitly converting the result to a string which is then used elsewhere.
I'm working on a Form that contains various fields for adding values (texttabs/ listtabs/ etc).
The form goes to two recipients, one of whom has access to half the fields which have been set to "concealed" (true) to prevent other recipients from viewing personal information.
My question is, is it possible to retrieve the Form Data (concealed values) via API? I'd like to reattach these concealed values to the final product in my API script once the form is completed in Docusign. I searched everywhere but could not find an answer.
Thanks,
Dan
Yes this is possible to do through the DocuSign REST API. It's not very intuitive but there's an API call you can make to retrieve the recipient entered values.
Have a look at the Get Envelope Recipient Status API call, and more importantly, it's one optional parameter. Details of the call are:
URL:
/accounts/{accountId}/envelopes/{envelopeId}/recipients
HTTP Method:
GET
Parameters:
The only required parameter is the envelope ID. If the optional query include_tabs is set to true, the tabs associated with the recipient are returned. If the optional query include_extended is set to true, the extended properties are returned.
-Example (from documentation)-
GET https://{server}/restapi/{apiVersion}/accounts/{accountId}/envelopes/{envelopeId}/recipients?include_tabs=true
X-DocuSign-Authentication: <DocuSignCredentials><Username>{name}</Username><Password>{password}</Password><IntegratorKey>{integrator_key}</IntegratorKey></DocuSignCredentials>
Accept: application/json
Content-Type: application/json
See the REST API Guide page 192 for more info on the call.
Here are the wireshark logs of 3 POST's. All posting the same data but with different content-types, resulting in different ways the data is read on the server. I'm attempt to to understand how to create POST Z.
POST X
Explicitly setting form based post
gives
POST Y
Omitted content-type
gives
POST Z ?
My app is not able to reproduce this.
gives
I'm attempting to guess what content-type in the last POST Z (notice there are no brackets), which made the post parameters appear as data ( and apparently without a data-type )
Thanks
~B
I'm attempting to guess what content-type in the last POST Z (notice there are no brackets), which made the post parameters appear as data ( and apparently without a data-type )
The content type is probably "none".
You're not obliged to send a Content-Type: header with a POST request. The HTTP 1.1 spec, RFC 2616, says in section 7.2.1 "Type":
Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, therecipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".
It says SHOULD, not MUST, so a sender is allowed to send an entity-body without a Content-Type: header.