I'm trying to use the FindPickup API of the HERE Waypoint Sequence Extension.
If I run the sample code, everything is working fine.
But if I remove the "end" parameter from the query string, I'm receiving the error "required parameter end is missing".
However, the API doc clearly states on several occasions that the "end" parameter is optional.
What am I missing?
I'm Richard and I'm a developer evangelist for HERE Technologies.
This is indeed an error in the documentation. I've let the team know and we will fix it. Thank you for pointing this is out!
To clarify: the end parameter is optional for the /findsequence resource, but required for the /findpickups resource.
Related
I don't see nextSyncToken in the response. I followed the doc(https://developers.google.com/calendar/api/guides/sync) and paginated using nextPageToken but I couldn't see the nextSyncToken on the last page.
API Used: GET /calendars/primary/events?maxResults=10&singleEvents=true&pageToken=********
I don't know whether if I miss anything here. Could anyone help me with this?
I have seen from the response link on the other answer comment that you are using orderBy on the request.
This is why the nextSyncToken is not showing up.
As mentioned on the documentation on Events: list -> Parameters -> syncToken:
Token obtained from the nextSyncToken field returned on the last page of results from the previous list request. It makes the result of this list request contain only entries that have changed since then. All events deleted since the previous list request will always be in the result set and it is not allowed to set showDeleted to False.
There are several query parameters that cannot be specified together with nextSyncToken to ensure consistency of the client state.
These are:
iCalUID
orderBy
privateExtendedProperty
q
sharedExtendedProperty
timeMin
timeMax
updatedMin
If the syncToken expires, the server will respond with a 410 GONE response code and the client should clear its storage and perform a full synchronization without any syncToken.
Learn more about incremental synchronization.
Optional. The default is to return all entries.
You should remove the orderBy from the request to get the syncToken
Could you please provide the response from gcalendar API? It's hard to say more without detail information. I event don't know which language are you using.
Try to use a vendor library to sort that out:
a) https://packagist.org/packages/google/apiclient (for PHP)
b) https://www.npmjs.com/package/google-calendar (for JavaScript)
and/or
Try to use alternative endpoint: GET https://www.googleapis.com/calendar/v3/calendars/calendarId/events.
I am faced with a LinkedIn sharing issue.
This issue probably reproducible from March 1st 2019.
I share some url e.g. https://www.linkedin.com/sharing/share-offsite/?url=SHARE_URL#HASH
Worked before: link in post(href) - SHARE_URL#HASH
Works now: link in post(href) - value of og:url meta tag from SHARE_URL#HASH page
So we lose request parameters in SHARE_URL and #HASH
How we can pass link for LinkedIn post into request?
You need to do URL-encoding with parameters you are feeding to another URL. So, this is what you should want...
https://www.linkedin.com/sharing/share-offsite/?url=SHARE_URL%23HASH
Remember, URL's use things like ? and # to indicate a special argument occurring after this character. So, for instance, example.com/share.php?title=thisistitleright?&..., how would the browser know that the first ? indicates the GET param and the second ? is a part of the title argument? Easy: URL encoding.
In case you want to know more: Official LinkedIn Share Documentation
I'm trying to call a receive pipeline from the orchestration in order to catch any type of flatfile_to_xml error.
After searching for tutorials, the process seemed quite easy.
Added the libraries, created my inputMsg of type xmlDocument to inglobe any non-Xml payload (in my case the content of my file.txt) and created an atomic scope containing an expression for:
Microsoft.XLANGs.Pipeline.XLANGPipelineManager
.ExecuteReceivePipeline(typeof(namespace.pipelineName), msgIN);
Too bad I get that ExecuteReceivePipeline can't accept a XmlDocument while it accepts only a Microsoft.XLANGs.BaseType.XLANGMessage).
Cannot connvert from 'System.Xml.XmlDocument' to 'Microsoft.XLANGs.BaseTypes.XLANGMEssage'
Why this, and how can I achieve what I'm trying to achieve?
You have to use a Message variable of type XmlDocument.
It look like you're using a variable of type XmlDocument.
Ok, now it's working and i'm not sure why.
At first the msgIN of type XmlDocument wasn't accepted as a valid parameter.
I then created a msgType of type XmlDocument, and assigned it as the type of the message, so that calling:
ExecuteReceivePipeline(typeof(namespace.pipelineName), msgIN)
would be valid. after many rebuild and deploy i switched back to msgIn as XmlDocument... and it worked as intended...
I don't get it, but it's not the first time that a rebuild or a close-and-reopen of VS solved my preblems.
Thanks for those who found the time to answer!
When try to update status with link in linkedin api i'm getting this error frequently.
Example Link:
http://www.world-grain.com/articles/news_home/World_Grain_News/2016/06/General_Mills_files_patent_on.aspx?ID={30B4213B-4E10-4AF6-9B56-0D5614D7AFD3}&cck=1
If i remove the { and } from the link it get posted. Even in linkedin site itself its not working.
Help me if anyone know the reason.
I was receiving the same error and the reason was that I didn't send values for all the keys in request's body. For example: "content" parameter in linkedin's request body is a dictionary with 4 keys:
title
description
submitted-url
submitted-image-url
I had no image url so I didn't set the key "submitted-image-url" at all. The solution was to set the value to empty string "".
I wonder why linkedin can't parse dictionary if it doesn't have all the keys but that's the way it works.
Hope this helps
You may need to URL encode the braces in your link:
http://www.world-grain.com/articles/news_home/World_Grain_News/2016/06/General_Mills_files_patent_on.aspx?ID%3D%7B30B4213B-4E10-4AF6-9B56-0D5614D7AFD3%7D&cck=1
I ran into the same error when I attempted to pass a URL with spaces. It published successfully after URL encoding the spaces (%20).
I know that in most MVC frameworks, for example, both query string params and form params will be made available to the processing code, and usually merged into one set of params (often with POST taking precedence). However, is it a valid thing to do according to the HTTP specification? Say you were to POST to:
http://1.2.3.4/MyApplication/Books?bookCode=1234
... and submit some update like a change to the book name whose book code is 1234, you'd be wanting the processing code to take both the bookCode query string param into account, and the POSTed form params with the updated book information. Is this valid, and is it a good idea?
Is it valid according HTTP specifications ?
Yes.
Here is the general syntax of URL as defined in those specs
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
There is no additional constraints on the form of the http_URL. In particular, the http method (i.e. POST,GET,PUT,HEAD,...) used don't add any restriction on the http URL format.
When using the GET method : the server can consider that the request body is empty.
When using the POST method : the server must handle the request body.
Is it a good idea ?
It depends what you need to do. I suggest you this link explaining the ideas behind GET and POST.
I can think that in some situation it can be handy to always have some parameters like the user language in the query part of the url.
I know that in most MVC frameworks, for example, both query string params and form params will be made available to the processing code, and usually merged into one set of params (often with POST taking precedence).
Any competent framework should support this.
Is this valid
Yes. The POST method in HTTP does not impose any restrictions on the URI used.
is it a good idea?
Obviously not, if the framework you are going to use is still clue-challenged. Otherwise, it depends on what you want to accomplish. The major use case (redirection of a data subset to a new POST target) has been irretrievably broken by browser implementations (all mechanically following the broken lead of Mosaic/Netscape), so the considerations here are mostly theoretical.