Loading Profile...
API issues
I've written a WCF client for all of the non-batch calls, but there are some issues that we have run into that are preventing us from using the API. We had been discussing them with John Donovan through email, but we haven't received replies for some questions, and the others have taken over 2 weeks to get a reply.
Problem #1 (unable to see if its been fixed due to Problem #2):
If there are fewer total results than the limit, then we will only get those results. However, if the total number of results exceeds the limit (n), then no matter what the offset is set to, we always get back n (limit) results. I know it sounds weird, but that is what we’ve observed. Here is an example:
If we set the limit to 100 and there are only 16 results total, we get those 16 results. If we set the limit to 10, we will always get 10 results back no matter what the offset if set too. Even if the offset is set to 10,000, we still get back 10 results. I haven’t tried it since I sent you the reply on 10/2/2009, but I can try it again if you like. This can be seen in the Daylife API Tester as well, which is where I first observed the issue.
Problem #2:
When setting the sort property to "date", the response is returning items in descending order, whereas the documentation states that it should be in ascending order. I'm hoping that this is just an error in the current server code as descending order means that we'll be receiving a huge number of duplicate responses.
Problem #3:
The API is not fully compliant with the WC3 specification while Microsoft wrote WCF to be strictly compliant to the WC3 specification.. There is also one compliance issue in the WC3 specification that contradicts a previous WC3 specification, and Microsoft unfortunately followed the rule that is in contradiction. The good thing is that I was able to completely work around that issue by using the XmlSerializer. That WC3 contradiction issue is related to the ordering of elements where the main text states that order cannot be guaranteed, while later text states that order must be specific. As you know, the ordering of response elements appears to be random, thus the default serializer does not work.
The issue that I am not able to work around is due to a violation in the QueryString request. The WC3 specification states that the name of all name-value pairs must be unique, and WCF does not allow this to be overridden. However, it can easily be fixed if the API is corrected to be WC3 compliant that does something like the following pseudo-code:
Good: topic_id=UrlEncode(UrlEncode(“topic1”)+“,”+UrlEncode(“topic2”))
Bad: topic_id=UrlEncode(“topic1”)&topic_id=UrlEncode(“topic2”)
Thanks,
Bill Bosacker
Problem #1 (unable to see if its been fixed due to Problem #2):
If there are fewer total results than the limit, then we will only get those results. However, if the total number of results exceeds the limit (n), then no matter what the offset is set to, we always get back n (limit) results. I know it sounds weird, but that is what we’ve observed. Here is an example:
If we set the limit to 100 and there are only 16 results total, we get those 16 results. If we set the limit to 10, we will always get 10 results back no matter what the offset if set too. Even if the offset is set to 10,000, we still get back 10 results. I haven’t tried it since I sent you the reply on 10/2/2009, but I can try it again if you like. This can be seen in the Daylife API Tester as well, which is where I first observed the issue.
Problem #2:
When setting the sort property to "date", the response is returning items in descending order, whereas the documentation states that it should be in ascending order. I'm hoping that this is just an error in the current server code as descending order means that we'll be receiving a huge number of duplicate responses.
Problem #3:
The API is not fully compliant with the WC3 specification while Microsoft wrote WCF to be strictly compliant to the WC3 specification.. There is also one compliance issue in the WC3 specification that contradicts a previous WC3 specification, and Microsoft unfortunately followed the rule that is in contradiction. The good thing is that I was able to completely work around that issue by using the XmlSerializer. That WC3 contradiction issue is related to the ordering of elements where the main text states that order cannot be guaranteed, while later text states that order must be specific. As you know, the ordering of response elements appears to be random, thus the default serializer does not work.
The issue that I am not able to work around is due to a violation in the QueryString request. The WC3 specification states that the name of all name-value pairs must be unique, and WCF does not allow this to be overridden. However, it can easily be fixed if the API is corrected to be WC3 compliant that does something like the following pseudo-code:
Good: topic_id=UrlEncode(UrlEncode(“topic1”)+“,”+UrlEncode(“topic2”))
Bad: topic_id=UrlEncode(“topic1”)&topic_id=UrlEncode(“topic2”)
Thanks,
Bill Bosacker
1
person has this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
The best solution from the company
-
Bill,
Addressing all the 3 issues below:
Problem #1: Limit is the number of results you want back. Offset helps you paginate through the result set if the total number of results is more than your limit.
So for e.g.:
a. Limit=10, offset=0 gives me first 10 results from the total resultset
b. Limit=10, offset=20 gives me the next 10 results
c. Limit=10, offset=30 gives me the next 10 results
.. and so on.
It is important to keep the limit fixed, and increase the offset by the same value as the limit as you paginate through results.
Problem #2: That was an error in the documentation. sort=date is supposed to return you results in a reverse chronological order, i.e. newest/latest item first. Thanks for pointing out the error.
Problem #3: You are absolutely right about the Daylife API response not guaranteeing the order of elements. The API XML response is just a structured XML and we do not aim to stick to any MS standards or even stick to a schema. Something that has been on our roadmap, but just not on near horizon for now.
The company says
this solves the problem
-
Inappropriate?Bill,
Addressing all the 3 issues below:
Problem #1: Limit is the number of results you want back. Offset helps you paginate through the result set if the total number of results is more than your limit.
So for e.g.:
a. Limit=10, offset=0 gives me first 10 results from the total resultset
b. Limit=10, offset=20 gives me the next 10 results
c. Limit=10, offset=30 gives me the next 10 results
.. and so on.
It is important to keep the limit fixed, and increase the offset by the same value as the limit as you paginate through results.
Problem #2: That was an error in the documentation. sort=date is supposed to return you results in a reverse chronological order, i.e. newest/latest item first. Thanks for pointing out the error.
Problem #3: You are absolutely right about the Daylife API response not guaranteeing the order of elements. The API XML response is just a structured XML and we do not aim to stick to any MS standards or even stick to a schema. Something that has been on our roadmap, but just not on near horizon for now.
The company says
this solves the problem
-
Inappropriate?Hi Vineet,
Problem #1:
I know that that is how it is supposed to work, the problem is that it does not work that way, as I stated in my first message. For example:
Lets say that I set a time block for the resultset for which I know that there are n results. If limit is less than or equal to n, I need to make multiple call requests, each with a sliding offset (i.e. offset=limit*iteration). The problem is that no matter what the iteration is, and thus the offset, your system will never return less that limit results.
I used the differing limits of 10 and 100 to prove the point. With a 100 limit I could see that there were only 16 results and thus I don't need to iterate further. However, with a 10 limit I get 10 results on the first iteration (line a in you example) and need to make a second iteration. On the second iteration (line b in your example) I again get 10 results instead of the 6 that I should, which is the problem. I can iterate forever and your system will always return 10 results.
Problem #2:
I was really hoping that this was not the case as it is going to cause a weird stair stepping as we poll your system for updates. Instead of receiving results in a chronological order, we'll be receiving them in a sawtooth staircase pattern. If there is any kind of failure, we will be left with a timespan hole that needs to be filled. The coding to detect this hole is going to be ridiculous and will most likely result in multiple duplicate resultset calls to ensure that there isn't a hole.
With a start date, no end date, and an ascending time line, we would never have a hole. All successive calls could be made with a start date of the latest received timestamp_epoch + 1.
Problem #3:
As I stated in the first message, there is a work-around for the mis-ordering of elements, so it does not need to be addressed. However, there is no work-around for the duplicate names violation in the request. For example, having 2 or more 'topic_id' name parameters in the request (i.e. "?topic_id=1&topic_id=2&topic_id=3&...") is a WC3 invalid HTTP request violation (not a Microsoft thing). That is what needs to be addressed.
Thanks,
Bill -
Inappropriate?Problem #1 appears to have been fixed now. I just did a test and it is now working. I may be seeing another issue now, but I need to look into it further.
-
Inappropriate?Ok, I figured out what I'm seeing now. If a start_time is set and there are no new articles since that time, the API is returning the following null <article> record:
<response><message type="str">Success</message><code type="int4">2001</code><payload><article /></payload></response>
Is this correct? I was expecting no <payload> at all, or a null <payload>. -
Inappropriate?Bill,
That is true - We return an empty <article /> tag inside <payload> if we do not have data as per your query/request.
You will have to check the emptyness of that <article /> tag in your code.
Vineet
</payload>
EMPLOYEE
