I am using a C# example provided by Workfront to interact with the Api.
https://developers.workfront.com/api-docs/code-samples/
I want to be able to update an Issue with a new categoryID or add the value when creating the Issue.
I'd also like to assign a value to one of the parameters in the category.
had same problem
this request works for me
> PUT https://{domain}/attask/api/v5.0/category/{categoryId}/assignCategory?objID={taskId}&objCode=TASK&categoryID={categoryId}
> Accept: application/json
> Content-Type: text/plain
notice to send body as empty plain text (it was my problem)
Related
I am trying to send a Get request with the following header:
Cookie: uac.csrftoken=VwJryg1rJBC3sddwHarr497lKgQgMq;
expires=Mon, 15-Nov-2021 12:12:24 GMT; Max-Age=31449600; Path=/;
uac.authorization=2dA2631879fc4dc2e9;
in NiFi I have sent a request to get the requiered parameters and assigned it to the flow file attributes :
Now I need to combine both to have the same format as the Header above,
what do I need to add to the field attributes to send to do that?
I tried multiple ways and nothing worked, it says here
I figured it out, This can be done by adding any custom Dynamic Property in the InvokeHTTPProcessor. Example in my case :
Trying to update a data field on a lead record in Marketo. Using C#. I send:
{"action":"updateOnly","input":[{"email":"dfranks#gmail.com","leadQuality":"Hot"}]}
And get back:
{"requestId":"d98e#14b2d7dd1f3","success":false,"errors":[{"code":"612","message":"Invalid Content Type"}]}
Why the Invalid Content type message? The field leadQuality is legit. The email address exists. I've tried a number of different fields and always the same message. Access token is good too.
Content-Type is a HTTP header. Usually, you set it to application/json for REST calls.
You should do this in the code where you generate the HTTP request or REST call.
I found text/json as Content-Type and Accept header value in one of the marketo examples. You might try one of the two choices.
Here are a couple of things to check:
As #StephenKing mentioned, I would check that your Content-Type HTTP
Header is set to "application/json".
I would also confirm that the custom field you created for "leadQuality"
has a String data type.
I'm using Jmeter version 2.9, HTTP sampler to test my rest services.
The GET and POST are working without any issues, where as PUT is not passing any parameters in the request to the server.
I verified it with view results in tree.
Any reasons on why this is happening and work around this issue?
It worked for me. Based on what I read on internet, there were different solutions suggested:
Changing Content-Encoding to UTF-8
Pass the PUT parameters in the "body data" tab (as opposed to passing them in tabular format in the "Parameters" tab)
Setting Content-Type header to application/json in the HTTP Header Manager
Passing the parameters via a file (even if this were to work, how would you pass dynamic values?)
passing it as POST with a combination of above points.
WHAT WORKED FOR ME is this combination: Set content type to application/json + Pass parameters as "JSON" in the **body data tab (below is an example)
I did not need to specify UTF-8 or anything else.
EXAMPLE JSON PARAMETER BODY:
{"title":"JMeterTitle","preMortar":"JMeterPre","postMortar":"JMeterPost"}
Pass parameters in path field using:
?name=value&name2=value2
and body in Raw Post body.
if it doesn't work report a bug .
Example:
I am using JMeter 2.11 and I had the same problem. I solved in this way:
1) Setting Content-Type header similar to that you are using in your api method(Example: application/json or application/x-www-form-urlencoded etc.) in the HTTP Header Manager.
2)In HTTP Request. Body Data should look like this:
KEY=VALUE&KEY=VLAUE&KEY=VLAUE&KEY=VLAUE.......
First, try see the logs.
Had a similar problem.
I was using wrongly the "Content-enconding" field as it were the HTTP
Content-Type param. They are not related.
If you need to set Content-Type=application/json you have to use a "HTTP Header Manager" config element.
After setting correctly Content-enconding to UTF-8 the put request started to work.
You should add a parameter with an empty name (in the "parameters" tab).
If the problem persists use the result tree view to analyze the request settings.
I'm using JMeter 2.13 and facing with similar problem. This is How I've solved it:
Setting Content-Type header to text/plain in the HTTP Header Manager
Changing Content-Encoding to UTF-8
In the parameters tab, add the params without name and separated with ampersand character (&)
Screenshot JMeter PUT request example
Hope it helps!
For a POST request, I got back a response in text/html format and the response body was containing the below info:
oauth_token=XXXXXXXXXXXXXXXXXXXXXXXXX&oauth_token_secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&oauth_callback_confirmed=true
I made this request through System.Net.Http.HttpClient and I throught I could read the response with FormUrlEncodedMediaTypeFormatter as FormDataCollection but it turned out that FormUrlEncodedMediaTypeFormatter only supports application/x-www-form-urlencoded format by default. So, I worked around this with the following code:
using (OAuthHttpClient client = new OAuthHttpClient(creds)) {
var response = await client.PostAsync(requestUri, new EmptyContent());
var formatter = new FormUrlEncodedMediaTypeFormatter();
formatter.SupportedMediaTypes.Add(new MediaTypeHeaderValue("text/html"));
var result = await response.Content.ReadAsAsync<FormDataCollection>(new List<MediaTypeFormatter>() { formatter });
}
The question here is:
Is the response provider (in this case it is Twitter) doing it wrong by sending this response as text/html or should FormUrlEncodedMediaTypeFormatter support text/html type by default?
Your question is missing some key info i.e. what is the requestUri supposed to return by default, is it a Web API service or an external one etc. It seems it's not Web API because it's little odd that it returns "text/html".
But the fact that FormUrlEncodedMediaTypeFormatter doesn't support formatting back from text/html is absolutely fine. Because why would it? "application/x-www-form-urlencoded" is effectively a key-value dictionary and text/html is a rich media type.
In Web API, with the way content negotiation works, it looks at
Mediatype mappings (I assume not in place in your case)
Accept headers - looking at your request you don't set them
Request content type - again, looking at your request you don't set it so it's empty
Can the formatter serialize a given type
So if you make the request as you showed to any Web API action, it would return text/xml (if you didn't tweak conneg manually).
I agree with Filip that this is a fine work around to an incorrect content type header.
Henrik
I'm playing with the Twitter API and noticed something funny- For updates, they require POST methods but expect the arguments in the query string. (See for example, the status/update call in their developer console here.)
Obviously this is technically possible, but why would anyone do it like that? Don't POST arguments belong in the body?
Either option is just as valid. My favourite example for using parameters in the URL for a POST is an application that sets waypoints on a map. e.g.
POST /map/route/45/waypoints?lat=35&long=74
In this case, the parameters make more sense in the URI as identifiers of a location, than just parameters being passed in the body to generic resource.
In REST architecture, GET and POST are just the verbs, which tells either to retrieve or create/update the resource. URI defines the identification of resource.
Example:
POST /student?name=Tom&age=12 >> It will create a new student with name Tom and age 12.
POST /student/10?name=Tom&age=12 >> It will update student with id 20 with name Tom and age 12.
There is no rule that the data should be binded to body payload or URI. This is different from WEB 1.0 concepts where HTML form data is sent in POST.
If the arguments for WEB API are in the body or query depends on the Content-Type header you send in the POST.
If it forinstance is Content-Type: application/json; charset=UTF-8 then the arguments are expected in the body as json. If it is Content-Type: application/x-www-form-urlencoded; charset=UTF-8 then the arguments are expected in the query string