|
|
|
Forum Member
Group: Forum Members
Last Login: 8/18/2008 7:37:50 PM
Posts: 35,
Visits: 63
|
|
Following up on my previous post, I see that each call to PostItem.aspx to submit post states results in a reponse with "the current state of all posts in any feed where read state has changed since the last sync."
This means that for every call, I receive a response of over 700kB, which takes anywhere from 1.5 to 4.5 seconds. That's a lot of bandwidth and time for a call that happens so frequently (in my case, to mark a post or group of posts as read).
I am not currently using any of the information in this response, so I'd love it if you could add a flag that would allow me to specify that I want the server to limit the response body to a simple "OK" or error, something like:
Request Format: application/x-www-form-urlencoded
"loc=<locationName>&r=<postId>&u=<postId>&d=<postId>&q=<0|1>"
o loc – specify the location name to submit the read state changes (OPTIONAL)
o r – mark a post read (can be specified multiple times)
o u – mark a post uread (can be specified multiple times)
o d - mark a post deleted (can be specified multiple times)
o q - specify 1 to request a "quiet" reponse from the server (i.e., omit the current state of all posts since the last sync)
Also, the draft of the new REST API documentation I have implies that this list of current posts should be limited to those that have changed since the last sync. However, I don't see how I can indicate when that happened. Should I add the last sync token from the location's OPML?
Thanks, all.
-- Dan
|
|
|
|
|
NewsGator
Group: Administrators
Last Login: 2 days ago @ 4:01:46 PM
Posts: 3,063,
Visits: 54,054
|
|
| Hey Dan, One of the API guys wants to go over this with you, we may have a beta API that you can use which could work better for you . Can you shoot an email to NewsGator Support - I'll make sure it gets to the right guys.
Jonathon McDougall
NewsGator Support
|
|
|
|
|
Forum Member
Group: Forum Members
Last Login: 10/20/2007 10:24:33 AM
Posts: 2,
Visits: 4
|
|
I'm also having a problem with the PostItem call. I working in a low-bandwidth, low-memory environment, so parsing 600k of return data each time a call is made is not feasible (really, ANY call that returns 600k is a no-go for me). I'm trying to figure out how to work the ng:token value into the call.
My app follows this basic sequence:
- Call Subscription.aspx/ to fetch a list of feeds
- Call Feed.aspx/ for each feed to get a list of posts for that feed
- When a group of posts has been marked read, or a timer fires, call PostItem.aspx to update the server with their read status
I've tried passing ?token=reallyLongTokenString with the PostItem call (using both the token returned by Subscription.aspx and the one from Feed.aspx), but neither one seems to effect the output. Any suggestions?
Thanks!
B
|
|
|
|
|
Forum Member
Group: NewsGator Staff
Last Login: 8/21/2008 1:38:55 PM
Posts: 18,
Visits: 99
|
|
| Hi Ben, In response to both yours and Dan's inquires, we have been working to implement the equivalent of the SOAP call PostItem.asmx/UpdatePostMetaData into the REST API. UpdatePostMetaData handles all of the read/flag state changes for a given feed/post. It definitely uses a sync token obtained from a previous Subscription.aspx call to keep results to a bare minimum. We hope to have a working version available to you for use in the coming weeks, so hang on!  -Rob NewsGator QA
|
|
|
|
|
Forum Member
Group: Forum Members
Last Login: 10/20/2007 10:24:33 AM
Posts: 2,
Visits: 4
|
|
Rob,
That's great news, thanks! Please let me know as soon as you're ready; I'll be glad to help test it out.
B
|
|
|
|
|
Forum Member
Group: Forum Members
Last Login: Yesterday @ 11:03:00 PM
Posts: 10,
Visits: 57
|
|
| Was the UpdatePostMetaData call ever finalized? It still says TBD in the docs. I'd like to be able to set the flagged state using the REST API.
|
|
|
|
|
Forum Member
Group: NewsGator Staff
Last Login: 8/21/2008 1:38:55 PM
Posts: 18,
Visits: 99
|
|
| This has slipped due to higher priorities, but let me take a look and see where we are at with the endpoint. Thanks, Rob
|
|
|
|