If I reply to a message using the API: https://learn.microsoft.com/en-us/graph/api/message-reply?view=graph-rest-1.0&tabs=http
, then where do I get the response id? Response is empty.
You won't get a response (or Location) header with either Send or Reply because they are asynchronous operations on the Exchange side (generally in the Graph if you used the Prefer return=minimal header you should get back a location response header with the Id of the item but because these ops are async there is no such Id at the time its accepted).
If you use CreateReply https://learn.microsoft.com/en-us/graph/api/message-createreply?view=graph-rest-1.0&tabs=http that will give you a draft item to work with and if you use immutableId's https://learn.microsoft.com/en-us/graph/outlook-immutable-id then you always have a reference to the response.
Related
I use graph api to create a message with attachment(s).
All runs fine but the server send back the complete message in response, including the attachments.
Is there a way to only get the message id in the response ?
I try with :
string webApiUrl = $"{_apiUrl}v1.0/users/{senderId}/messages?$select=id"
but I still get the whole message with 98ko of attachment.
You can do it using the prefer:return=minimal header in the request which will mean you will just get a 204 response. However the id of the item that was created will be returned in the location header (the response should really have the OData-EntityId if they are following the oData spec to the letter, also I'm not sure why it return the Outlook v2 location rather then the graph but the message Id is the same between them)
when i called the apple api: https://api.storekit-sandbox.itunes.apple.com/inApps/v1/history/{originalTransactionId} or https://api.storekit.itunes.apple.com/inApps/v1/history/{originalTransactionId} , http response 404
and when i check the apple document https://developer.apple.com/documentation/appstoreserverapi/get_transaction_history?language=objc , i found that,404 is(AccountNotFoundError | AccountNotFoundRetryableError | AppNotFoundError | AppNotFoundRetryableError | OriginalTransactionIdNotFoundError | OriginalTransactionIdNotFoundRetryableError)
but i only can see 404, not 404xxx ;
thanks for your help;
Is it possible that you have not replaced the {originalTransactionId} with the original transaction ID value provided by Apple during the purchase?
In StoreKit v1, upon a purchase, Apple will return your app a base64 encoded string of receipt data.
Your app will have to pass this string back to you backend service.
Later on, from your backend, you can invoke /verifyReceipt to get decoded transaction information. In the in_app field of the response you will be getting a series of transactions including an original transaction ID for each one.
Now you can invoke https://api.storekit-sandbox.itunes.apple.com/inApps/v1/history/{originalTransactionId} for each transaction in the in_app array in the previous response, by replacing {originalTransactionId} with each of the original transaction IDs you received in the previous call.
Regarding the 404 response you received: 404 is a standard HTTP status code meaning "NOT_FOUND". In order to get more information about the error you need to inspect the HTTP response body. There, according to the documentation, you will receive an error code indicating the exact nature of the error.
I'm using python to make calls to the Graph API regarding planner and tasks. whenever I use PATCH to try and update the task I get a 204 response back and the task remains unchanged. According to Microsoft's documentation here, this request should always return either a 200, or a 400 level error.
I have tried changing the data that I send to the server, to change the title rather than the dates, however I get the same 204 response no matter what data I send or what field I attempt to change. I have no problem making other graph calls like updating files in One Drive or getting data about a user
def SetDates(task):
'''Update planner to match the start date and due date of the passed in task'''
tid = task["id"]
start = task["startDateTime"]
end = task["dueDateTime"]
newDates = {"dueDateTime": end,"startDateTime": start}
etag = task["#odata.etag"]
session.headers.update({'If-Match':etag})
response = session.patch(f"https://graph.microsoft.com/v1.0/planner/tasks/{tid}", data = newDates)
session.headers.pop('If-Match')
print(task["title"] + " Has been scheduled")
Based on the documentation I expect this to return a status code of 200, and for the response to contain the data of the task that was updated, and for the change to actually be applied to the task.
By default, PATCH requests return an empty response with 204 return code. To get the data updated data back, you should send "Prefer" HTTP header with value "return=representation".
PATCH https://graph.microsoft.com/v1.0/planner/tasks/{task-id}
Content-type: application/json
Content-length: 247
If-Match: W/"JzEtVGFzayAgQEBAQEBAQEBAQEBAQEBAWCc="
Prefer: return=representation
I have finally figured this out.
#Tarken Sevilmis mentioned that in order to get a 200 response from a PATCH request you need to add
Prefer: return=representation
to your request. In my case the reason that my changes weren't being applied was because I hadn't set the content type in the header. The Graph API didn't give an error, but this seems to have been the cause of the issue. Once I set the content type to application/json it gave a proper error indication that the values I gave in the body weren't being read correctly, and I realized that I forgot to parse them to JSON.
Once you set the content headers appropriately and make sure to convert your data to proper JSON everything should work as intended
I'm unable to implement request/reply pattern using rest protocol with solace.
I'm correctly receiving a request and I can see some headers like "solace-correlation-id" and "solace-message-id".
What I'm expecting is to return an http response with the body as message reply but I always get in my application:
org.apache.camel.ExchangeTimedOutException: The OUT message was not received within: 20000 millis due reply message with correlationID: xxxxx-1549904557890-0-26 not received on destination: #P2P/QTMP/v:cfdce68771f5/c9c4ba4a-a427-438a-9b7a-1f069608d13a.
Unfortunately the solace documentation only covers pub/sub pattern for rest but not the request/reply one.
There could be a few different things going on here.
Firstly try adding the log component between the "from" and "to" endpoints and again after the "to" endpoint as this will show you the headers of the reply, for example, using the Java DSL syntax:
from("{{fromSource}}" )
.to("log:all?level=INFO&showAll=true&multiline=true")
.to("{{toDest}}" )
.to("log:all?level=INFO&showAll=true&multiline=true")
;
I suspect the correlation id is not getting passed back. In my example I have a a NodeJS service so I set the following response header:
res.setHeader('solace-correlation-id', req.get('solace-correlation-id'));
With the additional logging, you should be able to see what is going wrong.
You are most likely missing the message ID or coorelation ID in your reply message.
https://docs.solace.com/RESTMessagingPrtl/Solace-REST-Message-Encoding.htm#2.2.6.1
When the Solace message broker receives a possible reply message routed to the HTTP client, it verifies that the reply message's message ID or correlation ID match those of the request message.
Specifically,
- the reply's message ID must match the request's message ID the
- reply's correlation ID must match the request's message ID, or the
- reply's correlation ID must match the request's correlation ID.
If any of those matches occur, the Solace message broker sends the reply message as an HTTP response to the HTTP client.
HTTP requires that there be exactly one HTTP response for each HTTP request, so each matching message ID or correlation ID can be used only in a single request-reply message exchange pattern.
If the reply message does not have a matching message ID or correlation ID as above, or if the reply message's matching message ID or correlation ID has already been consumed by an earlier reply message, the reply message is discarded.
I'm not sure when this started happening (I believe fairly recently). This is a breaking change if you rely on the steps documented here:
https://msdn.microsoft.com/en-us/office/office365/howto/sync-calendar-view
The issue is that the the Office 365 & Outlook.com calendarview api no longer seems to return a #odata.nextLink when there is more data to be fetched if you specify "odata.track-changes" for the "Prefer" header in your request.
Here is a CURL request to repro the issue... be sure make the request authenticated as a user with at least 50 events during the time frame specified (to trigger paging).
curl -H "Authorization: Bearer <OMITTED>" -H "Accept: application/json; odata.metadata=none" -H "Prefer: odata.track-changes" "https://outlook.office.com/api/v2.0/me/calendarview?startdatetime=2016-06-16T00:00:00Z&enddatetime=2017-06-23T00:00:00Z"
When I make this request, the resulting response has 10 entries (even though there are at least 50 events) and the response does not have an #odata.nextLink. It does have a #odata.deltaLink however.
Is anyone else experiencing this issue?
As far as I know it has always worked this way. The initial sync returns a deltaLink instead of a nextLink. You have to treat that initial sync request specially and go ahead and issue the next request using the deltaToken.
Initial sync request: The very first sync request sets up the sync state.
Initial sync response:
Check for "Preference-Applied: odata.track-changes" in the response header to confirm a successful sync attempt and the resource supports synchronization.
If the sync attempt was successful, the initial response always contains an #odata.deltaLink with a deltaToken value. If the response contains any data, save the deltaToken value for the second request.
If the initial response wasn't successful, or doesn't return any data indicating there are no events in the specified calendar view, this round of sync ends.
Subsequent sync request: Use the deltaToken or skipToken value from the previous request to issue the next request. See the second and third sync requests as examples.
Subsequent sync response:
If the response returns any data, and, there is more data to sync in that time range, the response would include an #odata.nextLink and a skipToken value. Save the skipToken for the next sync request.
Go back to step 3, follow the nextLink, if any, apply the corresponding skipToken value in the next sync request, and follow any subsequent nextLink, until you have synchronized all the data in the time range for that calendar.
Final sync response: When all events in the calendar view are synchronized, the final response in this round would include an #odata.deltaLink and a deltaToken again. Save the deltaToken value for the next round of synchronization.