I am getting the posts from linkedin but on the response I'm getting the commentary with all the supported elements(TextElement, MentionElement,HastagTemplate).
Can we do some filters on the request in order to only get plain text ?
This is my api endpoint
https://api.linkedin.com/rest/posts?author=urn%3Ali%3Aorganization%3A2127&isDsc=false&q=author&count=100
This is the response I'm getting nowadays
Congratulations to #[Becca Meinz] (urn:li:person:6sc1MHJfcE), Vice President of Best Buy's End-to-End Supply Chain Strategy, for her inclusion on #[Business Insider] (urn:li:organization:683279)'s 100 People Transforming Business list. https://bby.me/wj29an
Related
I want to get the timestamp of the last message in a channel using my bot. The problem is that other bots can post in the channel too and according to the FAQ the following restriction exists:
Bots talking to each other could potentially get stuck in unwelcome loops. To avoid this, we decided that bots will not be able to see messages from other bots regardless of mode.
I understand the reason, but I don't want really read these messages. I just want to know the last date of the post (because I don't want them post too often).
I am sending an RME request to obtain speed limit and traffic light information and get back a JSON response. As Here-API provides a lot of different traffic sign types I dont care for (e.g. overtaking etc.) I cannot figure out how those types I am interested in are numerically encoded.
Browsing through the online docs provided by Here I could did not find the information I'm looking for, i.e. enumeration codes assigned to traffic lights
The request I send out looks something like
https://rme.api.here.com/2/matchroute.json?
app_id=<my-app_id>
&app_code=<my-app-code>
&routemode=car
&file=<zip and base64 encoded route info>
&attributes=BASIC_HEIGHT_FCn(*),ROAD_GEOM_FCn(*),ADAS_ATTRIB_FCn(*)
&attributes=ADAS_ATTRIB_FCn(*),SPEED_LIMITS_FCn(*),TRAFFIC_SIGN_FCn(*)
Please see below documents page and go to layers section and check the currently supported layers with the resource Layers.
https://developer.here.com/documentation/fleet-telematics/dev_guide/topics/here-map-content.html
For examples, this link will show about the layer of TRAFFIC_SIGN_FC1 in detail.
https://fleet.api.here.com/1/doc/layer.html?region=WEU&layer=TRAFFIC_SIGN_FC1&app_id={{app_id}}&app_code={{app_code}}
I want to know if there is any api that can allow me to get the number of reviews from an url.
I know that google offers the possibility to get this number by using the placeid, but the only information I have is the url of the website of a company.
Any ideas please?
Maybe, but probably not.
Places API Text Search seems to be able to find places by their URL:
https://maps.googleapis.com/maps/api/place/textsearch/json?key=YOURKEY&query=http://www.starbucks.com/store/1014527/us/303-congress-street/303-congress-street-boston-ma-02210
However, this is not a documented feature of the API and I do not think this can be relied upon, so I'd recommend filing a feature request, to make this a supported, reliable feature.
As for the amount of reviews, you may be interested in:
Issue 3484: Add # of reviews to the Place Details Results
I've written an API like this for Reviewsmaker, but I target specific business names not URLs. See this example (I activated a key for this purpose for now):
http://reviewsmaker.com/api/google/?business=life%20made%20a%20little%20easier&api_key=4a2819f3-2874-4eee-9c46-baa7fa17971c
Or, try yourself with any business name:
http://reviewsmaker.com/api/google/?business=Toys R Us&api_key=4a2819f3-2874-4eee-9c46-baa7fa17971c
The following call would return a JSON object which shows:
{
"results":{
"business_name":"Life Made A Little Easier",
"business_address":"1702 Sheepshead Bay Rd, Brooklyn, NY 11235, USA",
"place_id":"ChIJ_xjIR2REwokRH2qEigdFCvs",
"review_count":38
},
"api":{
"author":"Ilan Patao",
"home":"www.reviewsmaker.com"
}
}
Pinging this EP using a Chronjob for example once every hour or two and return the review_count can pretty much build your own review monitoring app;
You can probably do what you're looking for if you query the Places API Text Search or the CSE (Custom Search Engine) API to lookup the URL, return back the matching name of the business associated with this URL and calling an endpoint like this one to return back the associated review count.
You can probably code this in py or PHP. Not sure how familiar you are with data parsing, but I was able to build my API based on Google's CSE API. CSE provides metadata in its results which contain the total reviews, so if you create a CSE engine and use the CSE API looking for business schemas, review schemas, etc; you can return back items and within the PageMap node there are objects with data that you need very little tweaking to do (such as string replacing, trimming) which will return back the values you're looking for.
Hope my answer helped, at least to lead you in the right direction :)
The EWS Managed API has a handful of functions for retrieving and managing email conversations (aka email threads). Unfortunately, a large part of them work only against new versions of Exchange (2013 etc.)
Outlook does implement email threading against older versions of Exchange. Perhaps it does this by managing the threads by itself (Outlook is a desktop application, the emails are copied on the local machine, therefore they can be easily grouped by Conversation Topic etc.).
Now, how can email threading be supported within a web application? What is usually done for supporting this feature in an Exchange client? By supported I mean:
retrieve first 10 conversations snapshots, then retrieve the next 10 conversations snapshots - that is, support for paging (retrieve pages on demand) - this data would be used to build a master view
retrieve all emails within a conversation - that is, retrieve the children of a conversation on demand) - this data would be used to build a detail view of a conversation.
Issues with EWS Managed Api etc.:
there is no Conversation.Bind(conversationId) in EWS Managed API
ExchangeService.FindItems(filter for ConversationTopic == "some topic") is by no means reliable (because there may be different conversations having the same topic)
ExchangeService.FindItems(filter for ConversationId == "QWERYUIO") - I could not figure out how to use this :) Is it possible to search for emails by ConversationId?
functions like ExchangeService.GetConversationItems() are only "applicable for clients that target Exchange Online and versions of Exchange starting with Exchange Server 2013."
What I am using now (as a workaround):
retrieve (on demand) a page of conversations using ExchangeService.FindConversation()
for each conversation in the retrieved page, read the Conversation.GlobalIds property
build an aggregate (an array) containing the values from all GlobalIds - by concatenating Conversation.GlobalIds of all the conversations
make an Exchange call to bind the ids to emails (ExchangeService.BindToItems)
perform a group-by operation of the emails (conceptually, it is a grouping operation, but implementation is not a trivial group-by call - emails cannot be grouped by ConversationId, as that property is not available when working against Exchange 2010, though the documentation does not specify this)
use the data to build the UI in one step (the list of conversations for the master view, the groups of emails for the detail view of each conversation) etc.
Some issues with the implementation described above
I am retrieving a lot of data from the server when calling the ExchangeService.BindToItems operation - the performance is not excellent, but it is not quite bad either. Of course, it would have been better to retrieve the emails only when the user wants to access the detail view of a specific conversation. A possible hack: hold the GlobalIds array somewhere in a hidden field, then use it to fetch the emails in order to build the detail view. I know that a GET request is limited in size, but however...
On email conversations / email threading, nobody knows which supports what:
Here it says that FindConversation(ViewBase, FolderId) is applicable for clients that target Exchange Online and versions of Exchange starting with Exchange Server 2013. On the other hand, here is written that the ExchangeService.FindConversation() function can be used for Versions of Exchange starting with Exchange 2010, including Exchange Online.
This is funny, too: Applies to: EWS Managed API | Exchange Server 2010 Service Pack 1 (SP1), BUT Ensure that you have an Exchange 2013 or Exchange Online service account with a major version of 15 or higher. :)
Here it says that the Item.ConversationId property is available in Versions of Exchange starting with Exchange 2010, including Exchange Online. But it is not :)
Note: I am not very sure about the support of the Item.ConversationId, as I do not have the code at hand and cannot perform a test right now. Therefore, please forgive me if that property is available after all when using EWS Managed API against Exchange 2010.
All in all,
do you have any ideas for implementing the email conversations / email threading feature in a web application, using the EWS Managed API against an Exchange 2010 server?
Thank you a lot for having the patience to read such a long post :)
Some references:
http://msdn.microsoft.com/en-us/library/microsoft.exchange.webservices.data.exchangeservice_methods%28v=exchg.80%29.aspx
http://msdn.microsoft.com/en-us/library/microsoft.exchange.webservices.data.conversation_members%28v=exchg.80%29.aspx
http://msdn.microsoft.com/en-us/library/office/gg274407%28v=exchg.80%29.aspx
http://msdn.microsoft.com/en-us/library/office/jj220497%28v=exchg.80%29.aspx
Implementing Outlook 2010's group by conversation using EWS and Exchange 2007
Exchange Webservice Managed API - Find items by extended properties
I've addressed some of the documentation questions you had in the comments, so I'm going to attempt to answer your real coding questions here.
To get your master view, ExchangeService.FindConversation is the right method to use. It does support paging by limiting the results to the number of conversations specified by the view parameter. You could call it on demand to get older and older results.
To get your detailed view, because ExchangeService.GetConversationItems isn't available on Ex2010, you can use ExchangeService.FindItems with an IsEqualTo SearchFilter that searches for items with a matching ConversationId (see code below). There's more information about search filters here: How to: Use search filters with EWS in Exchange.
In the following method, I limited the properties of the FindItems call by specifying a property set, and not returning all the properties. If you wanted to return all the properties, you would just remove the line that sets the PropertySet.
static void forumFindConversationItem(ExchangeService service)
{
ItemView view = new ItemView(10);
//Remove the following line if you want to get all the properties for each message. This will limit the properties returned in your results (and save time).
view.PropertySet = new PropertySet(EmailMessageSchema.Subject, EmailMessageSchema.DateTimeReceived);
SearchFilter.IsEqualTo conversationFilter =
new SearchFilter.IsEqualTo(EmailMessageSchema.ConversationId, "AAQkADIwM2ZlM2ZlLWMwYjctNDg2Ny04MDU0LTVkMTFmM2IxY2ZjZQAQANEDR7V/30dphLiNOLSTuxE=");
FindItemsResults<Item> results = service.FindItems(WellKnownFolderName.Inbox, conversationFilter, view);
}
Once you have each ItemID (returned by the code above) you could use the Bind method to get all the properties on each item.
Hope that helps. I'll follow up when the versioning issues for the methods on MSDN have been updated.
More generally, there seems to be an issue with the ConversationID as it is popularly understood and actually used in Exchange itself. This could impact your (or anyone's) development.
I have been working on an email ticketing program in production and was using ConversationID to cluster emails together in a single thread for easy viewing.
But it now appears that there are emails that are not on the same thread -- yes, they share the same Subject and From Address and are sent around the same date/time -- but they do not occur in citation of each other (e.g. one email body in response to an older one is how many construe an "email thread") -- yet these disparate emails have the same exact ConversationID, even though one body has nothing to do with another.
In fact, even if the date/time is not close, for example, a "Thought of the Day" email from the same person, those will sometimes be grouped with the same ConversationID. This may sound useful in that case but is not so useful in the business case of a payroll person sending "RE: 401k".
To be clear, this is not a case-sensitive overmatch, an oversight I had when using Item.ExchangeID before (which is unique if you account for case). Even accounting for case, wholly different email threads have the exact same ConversationID.
This suggests to me one cannot depend upon ConversationID as a GROUP BY clause and must use some additional, custom-created code.
What's the best way to track RSS subscribers reliably without using Feedburner? Some of the obvious approaches like tracking by IP or by the number of hits have some fata flaws. IP addresses can change with each request or multiple users can use the same IP. Also, feed readers can request a feed multiple times per day or even hour. Both problems make it really hard to get reliable stats on unique subscribers.
I've read articles by both Leo Notenboom and Tim Bray on the topic, but none of their suggestions seems to really solve how to track subscribers in an accurate and reliable way. Leo suggests having a unique ID generated programatically to be appended to the RSS feed URL for each time the referring page is loaded. Tim advocates having RSS readers generate a unique hashtag and also has suggestions ranging from tracking the referrers to using cookies. A unique URL would be reliable, but it has two flaws: It's not a user-friendly URL and it creates duplicate content for SEO. Are there any other reliable methods of tracking RSS subscribers? How does Feedburner estimate subscribers?
There isn't really a standard way to do this. Subscriber counting is always unreliable but you can get good estimates with it.
Here's how Google does it (source):
Subscribers counts are calculated by matching IP address and feed reader
combinations, then using our detailed understanding of the multitude of
readers, aggregators, and bots on the market to make additional inferences.
Of course part of this is easy for Google, as they can first calculate how many Google Reader users are subscribed to the feed in question. After that they use IP address matching also, and that's what you should use too.
You could calculate individual IP addresses (i.e. unique) from the web-servers logs, but that would count 10 people as 1 if they all use the same address. That's why you should inspect the HTTP-headers which are sent by the client, more specifically header fields HTTP_X_FORWARDED_FOR and HTTP_VIA. You could use the HTTP_VIA address as the "main" address, and then calculate how many unique HTTP_X_FORWARDED_FOR addresses are subscribed to the feed. If the subscriber doesn't have these proxy-added fields, then it's counted as a unique IP address. These should be handled in the code that generates the feed. You could also add a GeoIP lookup for the IP's and store everything to a database. This would allow you to see which country has the most subscribers to your feed.
This has it's problems too. All proxies don't use these fields and it doesn't fix the problem of calculating subscribers behind NAT gateways. It is however a good estimate. Besides, you are probably more interested in the order of magnitude rather than the exact count of subscribers, aren't you? If the counter says that you have 5989 subscribers you probably have more subscribers as the counter gives you the lower bound.
Standard and Reliable are not exactly word in RSS dictionary :-) Got to remember that the thing doesn't even have standard XSD after how many years ? If by tracking you mean the "count" there are a few things you can do and the tactics depend on the purpose i.e. are demonstrating a big number or small number? It is a marketing thing so you have to define your goals :-)
You may have to classify IP numbers for a start - to have the basic collection of big / corporate / umbrella IP numbers. For them, you can use referrer as a reasonable filtering criteria and count everything else as unique unless proven otherwise. Vast majority of IP numbers remain stable for about 2 days but again it always good to use basic referrer logic as a filter for people who just keep "clicking" so to speak.
Then you need a decent list of aggregators and a classification on how they process URLs and if they obscure end readers completely then you need either published or inferred averages - it's always fair game to use equitable distribution of an average count. Using cookies may help to collect aggregator IPs and differentiate between automated agents and individuals.
One very important thing is to keep in mind that you can't use just one method and expect it to be a silver bullet - you need to use these 3-4 aspects at the same time plus basic statistical reasoning.
You could query your web server logs for traffic to your RSS feed, perhaps filter it by IP to get the number of uniques.
The problem is, that would rely on folks checking the feed daily. The frequency of hits to your RSS feed by one individual could vary day to do and the number could be lower.
If you configure your RSS feed to require some kind of authentication, you can do user-based metrics instead of ip-based metrics. Although this would be a technically-correct solution, getting people to opt into an authenticated blog in anything other than an Intranet scenario is a stretch.