Details

      Description

      Per https://dev.twitter.com/blog/changes-coming-to-twitter-api, Twitter is due to release version 1.1 of their API very soon. When that happens, the 1.0 API will be deprecated for 6 months before being removed.

      The key things that will need to be addressed:

      • Change the base endpoint URL to reference version 1.1. Although the details for this have not been released, there is some indication that it may be the same base URL as version 1.0, only with "1.1" in the URL instead of "1".
      • All endpoints will require authentication. Aside from enforcing this on every API binding method, this also means that it will no longer make any sense to offer a TwitterTemplate with a default constructor.
      • All endpoints will have rate limiting imposed. This may not have any direct impact on the API, but I'll want to keep an eye on how RateLimitStatus is populated to make sure it's compatible with 1.1.

      In addition, all endpoints should be reviewed to ensure accuracy and completeness with the API binding.

      Note that this issue is associated with both Spring Social Twitter versions 1.0.3 and 1.1.0. If 1.1.0.RELEASE is pushed prior to the 6 month deprecation window closing, then version 1.0.3 won't be necessary and Spring Social 1.0.x users can still use Twitter's 1.0 API; and encouraged to use Spring Social 1.1.x for Twitter 1.1 compatibility.

        Activity

        Hide
        Craig Walls added a comment -

        Twitter released version 1.1 of their API on 9/5/2012. See https://dev.twitter.com/blog/current-status-api-v1.1

        Show
        Craig Walls added a comment - Twitter released version 1.1 of their API on 9/5/2012. See https://dev.twitter.com/blog/current-status-api-v1.1
        Hide
        Craig Walls added a comment -

        This spreadsheet summarizes some of the differences between 1.0 and 1.1: https://docs.google.com/spreadsheet/pub?key=0AhjQotX9U0bJdElfR01CM1ZQcHBMRXUyUHlxZFJZalE&output=html

        Show
        Craig Walls added a comment - This spreadsheet summarizes some of the differences between 1.0 and 1.1: https://docs.google.com/spreadsheet/pub?key=0AhjQotX9U0bJdElfR01CM1ZQcHBMRXUyUHlxZFJZalE&output=html
        Hide
        Jeremy Appel added a comment -

        Craig et al,
        I have started to work on this task. I have run into a couple of questions that I would like to get your opinion on. First, the resource /get/blocks/blocking under v1 has been changed to get/blocks/list under v1.1 and now only allows for a cursor parameter (previously there were page and per_page parameters that were being employed). I assume the cursor parameter should be employed and if so how would you like to reuse the functionality that exists currently in FriendTemplate for creating a CursoredList<TwitterProfile>?

        Second, The application/rate_limit_status resource under v1.1 provides rate limits per method rather than the global limits that are provided by the current API. The method accepts a resources parameter that can be used to limit the rate limit status for each of method of a resource family that is provided e.g. statuses, search. I am assuming that the implementation will need to allow for the ability to limit the method invocation by a list of resource families as well as support querying all resource families and return a MultiValueMap with rate limits for each method of a resource family. Is that an acceptable implementation?

        Show
        Jeremy Appel added a comment - Craig et al, I have started to work on this task. I have run into a couple of questions that I would like to get your opinion on. First, the resource /get/blocks/blocking under v1 has been changed to get/blocks/list under v1.1 and now only allows for a cursor parameter (previously there were page and per_page parameters that were being employed). I assume the cursor parameter should be employed and if so how would you like to reuse the functionality that exists currently in FriendTemplate for creating a CursoredList<TwitterProfile>? Second, The application/rate_limit_status resource under v1.1 provides rate limits per method rather than the global limits that are provided by the current API. The method accepts a resources parameter that can be used to limit the rate limit status for each of method of a resource family that is provided e.g. statuses, search. I am assuming that the implementation will need to allow for the ability to limit the method invocation by a list of resource families as well as support querying all resource families and return a MultiValueMap with rate limits for each method of a resource family. Is that an acceptable implementation?
        Hide
        Rick Whitesel added a comment -

        Has there been any progress on this issue? Twitter has already begun to make changes.

        Show
        Rick Whitesel added a comment - Has there been any progress on this issue? Twitter has already begun to make changes.
        Hide
        Craig Walls added a comment -

        Yes, Jeremy has already performed a great deal of work in this area and I intend to review and push it forward in the next couple of weeks (now that my time is more clear after SpringOne/2GX). Twitter's 1.0 API will go away in March 2013, so we have a little time. But I do want to push this out in a 1.1.0 release, with a milestone release soon (again, hoping that post-S2GX I'll have more time to focus on this).

        Show
        Craig Walls added a comment - Yes, Jeremy has already performed a great deal of work in this area and I intend to review and push it forward in the next couple of weeks (now that my time is more clear after SpringOne/2GX). Twitter's 1.0 API will go away in March 2013, so we have a little time. But I do want to push this out in a 1.1.0 release, with a milestone release soon (again, hoping that post-S2GX I'll have more time to focus on this).
        Hide
        Rick Whitesel added a comment -

        From what I have read on this page, you plan to handle the individual rate limits, correct? Also how are errors handled in the framework. We have our own framework and are thinking about switching over to Spring Social. One issue for us is that we do as much of the authentication / authorization processing as we can in the server, as opposed to the web client. In any case, the Spring framework is a very nice piece of work!

        -Rick

        Show
        Rick Whitesel added a comment - From what I have read on this page, you plan to handle the individual rate limits, correct? Also how are errors handled in the framework. We have our own framework and are thinking about switching over to Spring Social. One issue for us is that we do as much of the authentication / authorization processing as we can in the server, as opposed to the web client. In any case, the Spring framework is a very nice piece of work! -Rick
        Hide
        Craig Walls added a comment -

        Thanks to a large contribution from Jeremy Appel, the latest snapshot build of Spring Social Twitter now has an API binding updated to Twitter's 1.1 API. Note that in Twitter's 1.1 API there are some endpoints that have been removed; the corresponding API binding methods in Spring Social have also been removed. As one example, TimelineOperations.getPublicTimeline() has been removed because Twitter's API no longer has an endpoint for the public timeline.

        Given the size of this effort, it's very likely that Jeremy overlooked something. I've tested it insomuch that it works with the Spring Social Showcase (and have updated the showcase as needed). But there could still be missing pieces or bugs.

        I encourage anyone who is interested to test it and report any gaps or bugs you find as separate JIRA issues. At this point, however, I'm going to close this issue as being complete...any additional work to fix bugs or fill gaps can be tracked in separate JIRA issues.

        Show
        Craig Walls added a comment - Thanks to a large contribution from Jeremy Appel, the latest snapshot build of Spring Social Twitter now has an API binding updated to Twitter's 1.1 API. Note that in Twitter's 1.1 API there are some endpoints that have been removed; the corresponding API binding methods in Spring Social have also been removed. As one example, TimelineOperations.getPublicTimeline() has been removed because Twitter's API no longer has an endpoint for the public timeline. Given the size of this effort, it's very likely that Jeremy overlooked something. I've tested it insomuch that it works with the Spring Social Showcase (and have updated the showcase as needed). But there could still be missing pieces or bugs. I encourage anyone who is interested to test it and report any gaps or bugs you find as separate JIRA issues. At this point, however, I'm going to close this issue as being complete...any additional work to fix bugs or fill gaps can be tracked in separate JIRA issues.

          People

          • Assignee:
            Craig Walls
            Reporter:
            Craig Walls
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: