I'm currently working on using Javascript to make REST calls to our Request Tracker system. The Javascript hasn't been a problem so far, but the documentation for RT+REST is just a little bit sparse. The goal is to claim a ticket. I've tried sending (POST):
REST/1.0/ticket/$num/take
And I get an error about not having a required parameter 'changes'
Then, I tried this:
REST/1.0/ticket/$num/take
id: $num
action: take
And I get the same error message. The last thing I've tried was:
REST/1.0/ticket/742685/edit
id: $num
action: take
And the response was "RT/ver 200 Ok" with all of the ticket information, but it didn't actually transfer ownership.
What am I missing?
On the off chance that someone else can use this, I think most of the RT REST/v1 endpoints require that all of the "key: value" strings be wrapped under a "content" key in the request payload. I also didn't see anything about a /take endpiont, so I might try something like:
var endpoint = base + 'REST/1.0/ticket/742685/edit'
var payload = {'content' : "id: 742685\n Owner: Some New Owner"}
makePost(endpoint, payload)
Worth a shot.
Related
We have stock website and we help buyers connect with the sellers. We are creating API to let buyers push their contact details and get back the seller details. This is transaction and get logged in our database. We have created following API:
The request is POST, the URL looks like:
/api/leads
The request body looks like:
{
"buyermobile": "9999999999",
"stockid": "123"
}
The response looks like:
{
"sellermobile" : "8888888888",
"selleraddress": "123 avenue park"
}
We have a new requirement, i.e. we need to send back PDF URL (instead of "sellermobile" & "selleraddress"). This PDF URL would contain the seller details in case it comes from one of our client.
We have modified the same API, now the request body looks like:
{
"buyermobile": "9999999999",
"stockid": "123",
"ispdf": true
}
The response looks like:
{
"sellerdetailspdf" : "https://example.com/sellerdetails-1.pdf",
}
Is it RESTFUL to do this? OR we should create separate API for getting response as PDF?
I wouldn't approach it this way. What happens when you need to add XLS? Do you add "isxls" to the request too?
Things I'd consider:
Use a mime type for content negotiation. Post the same request, and specify in the Accept header what you expect back - JSON, PDF, etc. You're then actually getting the report instead of a link to the report, which may or may not be better.
- or -
Include a link in the typical lead response.
{
"sellermobile" : "8888888888",
"selleraddress": "123 avenue park",
"_links": {
"seller-details-pdf": "https://example.com/sellerdetails-1.pdf"
}
}
- or -
Support a query parameter that specifies the type in the response.
- or -
Have a single property that specifies the type in the response, rather than a boolean. Much cleaner to extend when you add new response types.
The first two options have the bonus that you don't require clients to handle multiple response types to a single request. That's not forbidden by any spec, but it's annoying for clients. Try not to annoy the people who you want to pay you. :)
Again the implementation looks good to me, however you could potentially look at breaking the return of the PDF URL to another endpoint maybe something like api/lead/pdf that way your request body is the same for api/lead and all subsequent endpoints under /lead. Allowing your routes and other code to handle small portioned tasks instead of having a route that handles multiple flags and multiple code routes.
That looks good to me - the same type of input should give the same type of response but in your case you have two different types of input - one with the "ispdf" flag and one without. So it's consistent to responds with two different types of response, one with the PDF link and one without.
That's still something you'll want to document but basically it's a correct implementation.
I was thrown into a pretty old project, which is made in classic ASP. For our needs, I need to make a simple curl-request, to update some data.
I'm pretty new to ASP, so I looked for similar problems. I stumbled upon this
question here:
How can I post data using cURL in asp classic?
I tried to adapt as much as possible, but it seems like I'm missing an important thing and here I need your help:
functions.asp
public function makeCurlRequest(strMethod)
Dim http: Set http = Server.CreateObject("WinHttp.WinHttpRequest.5.1")
Dim privateKey
privateKey = "abc def"
Dim url: url = "https://sandbox.uberall.com/api/locations/322427?private_key=" & privateKey
Dim data: data = "{""location"":{""openingHours"":[{""dayOfWeek"":1,""from1"":""07:01"",""to1"":""07:02""}]}}"
'method needs to be PATCH
With http
Call .Open(strMethod, url, False)
Call .SetRequestHeader("Content-Type", "application/json")
Call .Send(data)
End With
If Left(http.Status, 1) = 2 Then
response.write("updated")
response.end()
Else
'Output error
Call Response.Write("Server returned: " & http.Status & " " & http.StatusText)
End If
end function
In my file, I simply call makeCurlRequest("PATCH").
Now it does indeed print "updated", so I guess I'm retrieving a 200, but the fields aren't updated.
Regarding to the uberall API, they require a location-object, which should be this, what is currently in my data-variable. (Checked it via a JSON-validator).
For a better readability, I'll provide the indented code as well, maybe here is an error:
{
"location":{
"openingHours":[
{
"dayOfWeek":1,
"from1":"07:01",
"to1":"07:02"
}
]
}
}
The ID's are correct, I double-checked that already. Maybe the payload is wrong? What might be the problem? Maybe data needs to be provided otherwise instead of this approach?
Looking at the examples on Uberall Tutorials Page
It looks as though the encapsulation of the location object is not necessary, instead structure the body like
{
"openingHours":[
{
"dayOfWeek":1,
"from1":"07:01",
"to1":"07:02"
}
]
}
In the code, change the data variable to be;
Dim data: data = "{""openingHours"":[{""dayOfWeek"":1,""from1"":""07:01"",""to1"":""07:02""}]}"
Must admit I had to dig around in the documentation to find an example that showed how they expected the body of the request to be structured, which isn't great for an API. Also if the payload was wrong you should be getting back an error so you know there was a problem with the payload, something along the lines of HTTP 400 Bad Request would make sense.
It's also possibly that the API uses HTTP 200 OK for everything, in which case any errors might get missed, so while testing you could just do something like this;
Dim http: Set http = Server.CreateObject("WinHttp.WinHttpRequest.5.1")
Dim privateKey
privateKey = "abc def"
Dim url: url = "https://sandbox.uberall.com/api/locations/322427?private_key=" & privateKey
'Purposefully passing the wrong structure to see what is returned.
Dim data: data = "{""location"":{""openingHours"":[{""dayOfWeek"":1,""from1"":""07:01"",""to1"":""07:02""}]}}"
'method needs to be PATCH
With http
Call .Open(strMethod, url, False)
Call .SetRequestHeader("Content-Type", "application/json")
Call .Send(data)
End With
'Not bothered about the status for now, just give me the response.
Call Response.Write("Server returned: " & http.Status & " " & http.StatusText)
Call Response.Write("Body: " & http.ResponseText)
I'm trying to use a service of DocuSign API in an abap project. I want to send a document to a specific email so it can be signed. But im getting the following error:
"errorCode": "INVALID_REQUEST_PARAMETER",## "message": "The request contained at least one invalid parameter. Query parameter 'from_date' must be set to a valid DateTime, or 'envelope_ids' or 'transaction_ids' must be specified.
I tried the following:
CALL METHOD cl_http_client=>create_by_url
EXPORTING
url = l_url (https://demo.docusign.net/restapi/v2/accounts/XXXXXX')
proxy_host = co_proxy_host
proxy_service = co_proxy_service
IMPORTING
client = lo_http_client
lo_http_client->request->set_method( method = 'POST').
CALL METHOD lo_http_client->request->set_header_field
EXPORTING
name = 'Accept'
value = 'application/json'.
CALL METHOD lo_http_client->request->set_header_field
EXPORTING
name = 'X-DocuSign-Authentication'
value = get_auth_header( ). (json auth header)
CALL METHOD lo_http_client->request->set_cdata
EXPORTING
data = create_body( ).
This is my body:
CONCATENATE
`{`
`"emailSubject": "DocuSign REST API Quickstart Sample",`
`"emailBlurb": "Shows how to create and send an envelope from a document.",`
`"recipients": {`
`"signers": [{`
`"email": "test#email",`
`"name": "test",`
`"recipientId": "1",`
`"routingOrder": "1"`
`}]`
`},`
`"documents": [{`
`"documentId": "1",`
`"name": "test.pdf",`
`"documentBase64":` `"` l_encoded_doc `"`
`}],`
`"status": "sent"`
`}` INTO re_data.
The api request to get the Baseurl is working fine. (I know the error is quite specific what the problem is, but i cant find any sources on the docusign api documentation that one of the mentioned parameters should be added to the request)
Thank you in regards
The error message seems to indicate that you're Posting to an endpoint that requires certain query string parameters -- but you're not specifying them as expected in the query string. I'd suggest you check the DocuSign API documentation for the operation you are using, to determine what query string parameters it requires, and then ensure that you're including those parameters in your request URL.
If you can't figure this out using the documentation, then I'd suggest that you update your post to clarify exactly what URL (endpoint) you are using for the request, including any querystring parameters you're specifying in the URL. You can put fake values for things like Account ID, of course -- we just need to see the endpoint you are calling, and what qs params you're sending.
To create an envelope, use
https://demo.docusign.net/restapi/v2/accounts/XXXXXX/envelopes
instead of
https://demo.docusign.net/restapi/v2/accounts/XXXXXX
Thank you for all the answers, i found the mistake. Creating the request wasn´t the problem. I was using the wrong "sending"-method -_-.
now its working :)
lo_rest_client->post( EXPORTING io_entity = lo_request_entity ).
I have a resource foo with the following structure:
GET /foo/1 returns:
{
"id": 1,
"server-key": "abcdef",
"status": "expired"
}
Status can either be active or expired. If it is expired I want the server to generate a new one.
Normally I'd issue PUT/PATCH foo/1 with the new key, but client doesn't know the key-generation algorithm.
I could also do a POST foo/1/server-key with no body, but that feels strange (I know this isn't very scientific reason though).
Any good ideas/patterns?
In case when you've got expired entity just make POST call on /foo without any parameters and server should return new entity (and HTTP response code should be 201):
{
"id": 2,
"server-key": "xyz",
"status": "active"
}
If some resourece is expired it is unconvinient to make it active again by PUT/PATCH request.
The approach I would adopt is to set a null value to server-key and let the server deal with it, but I do that because it's a consistent behavior in my APIs for the server to fill missing values with defaults.
Other than that, a simple POST to the URI as suggested in the other answer is adequate.
I think that you should use a PUT/PATCH method in your case to ask for generate a token if expired. Generally it's not really RESTful to put an action name within the resource path ;-)
I would see something like that:
Get the element: GET /foo/1
If the status is expired, ask for a new server key to be generated: POST /foo/1. In this case, this method will be used to execute an action to reinitialize the key on the server side
Using the method PUT corresponds to update the complete representation with a new one provided by the client. With the method PATCH, you will do a partial update of the representation.
Here is a link that could give you some hints about the way to design a Web API (RESTful service): https://templth.wordpress.com/2014/12/15/designing-a-web-api/.
Hope it helps you,
Thierry
It used to be that the response from a request gave us an array of request ids (as described here http://developers.facebook.com/docs/reference/dialogs/requests/) but it seems now the response variable returns two items insead 'to' and 'request'. To being a comma delimited string of user ids and request being a request id. Is this correct? I have seen nothing about this anywhere but it is the behavior I am seeing currently.
Update
Here is a super simplified version of my call:
FB.ui({method: 'apprequests', message: 'My Great Request'}, requestCallback);
function requestCallback(response) {
for(var key in response){
console.log(key);
console.log(response[key]);
}
}
When I make a request to one person the variable response has two keys: request and to. Request is a request id, to is the id of the person I'm sending the request to. If I make a call to the graph api using the provided request id, however, I find that the user under both 'to' and 'from' are equal to the sender's name and fbid.
Alternatively, if I request to multiple people request is equal to a single request id and to is an array containing all the fbids of the users that had requests sent to them. When I make a call to the graph api, however, I once more find that both 'to' and 'from' contain the user id and name of the requesting user.
I faced similar issue yesterday. Had to fix my code. But today request_ids were back in the response. So I updated the code again. But this time to work with both type of objects.
I found the documentation here (move down to the "Performance improvements" section)
http://developers.facebook.com/blog/post/569/
But it still doesn't explains why they reverted the change today. Or was it accidently released yesterday.
As in the documentation, the new callback will receive an object (response) that contains an array (request_ids) of request ids:
{
"request_ids": [
0: [request_id]
1: [request_id]
...
]
}
So I suppose you can loop using this modified code:
function requestCallback(response) {
for( var k in response.request_ids ) {
console.log(k);
console.log(response.request_ids[k]);
}
}
There is already a bug filed here
http://developers.facebook.com/bugs/129565473812085
There is no clear information yet whether the response is really changed or its a bug.