MySpace Developer Team : REST

New Features for OpenSocial 0.9 REST APIs

krunal — Wed, 18 Nov 2009 00:38:00 GMT

Hi everyone,

We are extending our 0.9 REST API offerings by adding new endpoints as well as adding new features to existing endpoints to make our 0.9 offering richer. We are committed to exposing data through Open Standards so app developers can create the finest applications on the web. Some of these new features are not part of the previous MySpace REST APIs so this should encourage you to switch to 0.9 if you haven’t done so already.

The link to the main resource page for REST 0.9 APIs is located here. Please find documentation links and highlights of these new features below. Please review our Terms of use, especially Section 10.2, before you start using these features.

New Endpoints

StatusMoodComments

This endpoint provides a way to fetch the comments posted on a user’s StatusMood updates. It also provides a way to request the comment author’s basic info (image, name and profile URL) along with the comments themselves. This could reduce the number of calls to the server you need to make if you plan on displaying the commenter’s data along with the comments.

Please see details here.

ProfileComments

This provides a way to fetch the comments posted on a user’s profile. It also provides a way to request the comment author’s basic info along with the comments, which again will reduce the number of calls to the server if that information is needed.

Please see details here.

MediaItemComments
You can now fetch comments posted on a user’s images and videos. Again, this endpoint allows you to fetch the comment author’s basic info to save a second request to the server.

Please see details here.

Enhancements

StatusMood

The StatusMood endpoints now offer APIs to fetch friends’ status mood updates as well as provides a way to fetch StatusMood history.
Apps can also fetch recent comments on a user status in the same call.
MySpace now allows syncing/updating StatusMood from various sources like Twitter. You can get that information in your requests.

Check the documentation for the StatusMood APIs here.

Also don’t forget to check out the filters that this endpoint has to offer.

Activities

We are also adding Activity Streams extension properties to activities returned from our OpenSocial 0.9 Activities endpoint in this release. Activity Streams is a data format that describes what people are doing around the web, for example: posting photos and videos, sharing music with friends and writing blog entries. If you are already familiar with the Activity Streams atom format, you can now access all the Activity Streams goodness, like actors, verbs, objects and object-types, in JSON and plain old XML. Find more information about Activity Streams on the http://activitystrea.ms web site.

Check out the MySpace implementation for the same here.

SDKs

Our PHP and Java SDKs have been updated to support these new features and the others are in the works. Also, these new features are developed using Open Standards like OpenID, OAuth and OpenSocial which should help make your experience smooth.

Also, if you have missed out, visit this earlier blog post for more information about complete suite of REST 0.9 APIs.

Happy coding!

REST App Notifications Are Now Available

Test User — Sat, 16 May 2009 00:26:00 GMT

We're happy to announce that we've just released the final piece of app notifications. You can now send app notifications directly from an OAuth REST end point. The REST end point allows you to pass in up to one thousand (1000) recipients at a time making it ideal for mass messaging communications to users of your app. This method also allows you to send notifications on a true server-to-server basis which is not initiated by a user action.

The general notifications page can be found in the developer Wiki. Documentation for the REST end point can be found here.

Enjoy!

Looking Forward to OpenSocial 0.9

Scott — Wed, 17 Dec 2008 22:00:00 GMT

The OpenSocial 0.9 draft has been defined. We are awaiting prototypes of all the new features before we declare the draft final. That means that, unless the spec is ambiguous or impossible to implement, the documentation is largely done. The set of changes accepted into 0.9 include some major additions to OpenSocial as a common platform. Given that platforms using OpenSocial touch over 600 million users (source), the changes effect a lot of people. The platform is open, meaning that it is guided by the community instead of by a single entity.

For v.NEXT, you are all invited to participate in the discussion we will continue to have at http://groups.google.com/group/opensocial-and-gadgets-spec/topics?hl=en. We really do need and want more developers to participate. Suggest features you would like to see. Tell the container developers that you love/hate an idea. Participate! A spec cycle lasts 3-4 months. During that time we: propose new features (6-8 weeks); discuss, refine, and vote on proposals (2-3 weeks); write a draft spec (2 weeks); review and vote on the draft (1 week). To be accepted, an item needs at least 5 votes for the feature and no votes against the feature. Because the process is open (as in open source), anyone can participate.

So, what do we have in store for you in 0.9 in terms of accepted proposals? The changes fall in a few different buckets: cleanup from previous iterations, enhancements to existing features, and introduction of brand new items. Oh yes, we are also deprecating some features as well. Note I said deprecating, not eliminating. As such, you shouldn't worry about features being removed. That will happen in the future and you will be warned when it happens.

Over the next couple weeks, I want to spend some time going over the changes that are coming up. In most cases, we build on the platform or simplify things. To give you a taste of what I'll be talking about, here is the list of changes coming in 0.9:

Changes/clarifications to existing features

Activity Paging: Added a class, opensocial.DataRequest.ActivityRequestFields, that has two values: FIRST and MAX. FIRST specifies the first item to fetch from the activity, MAX indicates how many to retrieve at once.
Align JS API and REST: The REST spec sees the Address element get updated to understand LATITUDE, LONGITUDE, and TYPE. Why? Not all locations have street addresses. And, the nearest street might be hundreds of miles away. Type is there to make labeling of addresses easier.
Align Portable Contacts and REST: Add language to the REST spec stating that we will work with the Portable Contacts folks to keep our specifications aligned. They did the same thing in their spec.
Anonymous Viewer: The spec did not say what the VIEWER ID should be if the VIEWER hasn't logged in. Most of the containers had decided that the value should be -1. Now, the spec will say that too.
Change to osapi:recipient format: The messaging part of the API did not give a way to indicate if a message was intended for a person (Scott) or a group (Scott's Top Friends). We added a string to the REST API saying that the ID can indicate the type of ID as group or person.
Clarify timing of callback execution in JS API: In some implementations, the callback might get called before the function to get data had returned. In others, the callback was always called later. This caused buggy behavior when switching platforms. So, in 0.9, we decided that the callback function will not be called until after the existing call stack has completed. (i.e. window.setTimeout(<callback closure>, 0);).
Implementing IS FRIENDS WITH: The 0.8.1 REST spec didn't say how to figure out how two people are friends. 0.9 will. Here is what we decided:

To determine if two people are friends:

/people/@me/@self?filterBy=@friends&filterOp=contains&filtervalue=<someUserid>

To find mutual friends between two user IDs

/people/@me/@friends?filterBy=@friends&filterOp=contains&filterValue=<someuserid>

filterValue can take a specific person identifier or @owner or @viewer

Radically simplify the Persistence/AppData API: Essentially, once you have a Person object, you can call getAppData(key) to get a specific piece of AppData.
registerOnLoadHandler: Spec was silent on what happened if the gadgets.util.registerOnLoadHandler was called many times. Now, it says that all functions will be called in the order they were added.
requestShareApp and requestSendMessage should use IdSpec: These were the only two functions in the existing API that took user IDs as strings instead of an IdSpec. Now, they take an IdSpec instead.
Resolve Schema with Portable Contacts: A stated goal of Portable Contacts and OpenSocial as that the Person and related objects should be compatible. We worked with the Portable Contacts folks to make sure that are schema is compatible.
Specify ownership of the page fragment identifier in the spec: The specification didn't say who owns the # portion of the ID. In reality, the containers all own it for various reasons. (See here for how to work around this.)

New Features (that will be the subject of my next series of posts):

Albums API
Content Rewriter Feature
Gadgets Log
International Date Time Number Formatting
Lightweight JS APIs
Limited Invalidation
Messaging API Changes
Min age metadata for ModulePrefs
OAuth Popup
OSML Tags
OpenSocial Templates
Overloading meaning of view
Proxied Content
UserPrefs for REST API
Versioning Applications

I'll work through the features, no more than 1000 words at a time. Some of these will be easy to explain, some more lengthy.

Finally, I want you to know that we are working hard to support these features. Every time we launch new features to better align with OpenSocial, we will broadcast where we are at.

NOW HIRING - MySpace Developer Platform Team

Allen — Mon, 19 May 2008 16:40:00 GMT

MySpace is expanding its Developer Platform Team!

Are you are knowledgeable in:

- AJAX
- C/C++
- Cross-Browser Support
- CSS 1.0 - 2.1
- DOM Levels 0 - 2
- HTML & XHTML
- Java
- JavaScript 1.0 - 1.5
- oAuth
- Object-Oriented Programming Concept
- .NET/C# 1.1 - 3.5
- REST
- WCF

Do you work in the Seattle, San Francisco, or the Los Angeles area (or want to)?

If so, we would like to talk with you!!!

MySpace recently launched the MySpace Developer Platform. We now have over 1200 live applications and growing everyday. We are hiring developers to help us expand our available APIs, evolve the MySpace Container, contributing & iterating to the OpenSocial Spec and libraries – among many other MDP related initiatives.

If you have a resume or questions, please email joe.darretta@fox.com. Please make sure you put "MDP" in the subject line (you don't have too, but it helps us)!