Whether you know it or not, some of the most interesting content on Meetup is not just in what you see in a group's photo album for an event or the discussion that goes on with in an event. There is also a lot of interesting content going on right in the group itself. You can check it out for yourself for any group with boards enabled at www.meetup.com/:urlname/messages/boards. The API team tries its best to expose features available on the site as a platform for developers to work with so we would be mistaken in our judgement if we did not expose this great group content as well. With that said, we are happy to announce you can now access group discussion content right from the API with these three new methods

All the methods above are immediately available to start using from the console

One thing you will notice is that there are some design changes in the style of these requests and responses. Below is a summary of those changes and the decisions for why we chose to make them

* Contextual queries are based on url path segments. 

One of the questions that we had to decide with each new method in version 1 and 2 of the API is how will people identify the resources requested in each method. Should it be one id or many ids. For groups, should it be group_id or group_urlname or domain. That's three separate parameters for identify the same resource. How can we make things more intuitive and discoverable for API users.

We found the answer to some of those questions in how members are already used to interacting with the site's URL design. In general, members on the site are more likely to be familiar with a urlname than a chapter_id off hand. I myself could not tell you the chapter id's of the groups I belong to without querying for them in the API first :) People are already used to visiting to a url like http://www.meetup.com/Meetup-API-Testing/ for the Meetup-API-Testing group's content. Thus, we have made a decision going forward to start designing group based API's around this familiar URL pattern. For those of you asking the question "what about custom domains?" the answer is that you can substitute domains for the urlname path element in any of the methods above, for example here are the boards for the group hosted at www.dashingwhippets.org

* JSON

If you've worked with the web APIs in the past 5 years you may have noticed that JSON is as has been for a long time the defacto standard for transport serialization. In the past, we have provided a number of formats for our API's. This does makes the API more flexible, but also adds more moving parts and sometimes more complexity in the decision making process for designing responses. Going forward, we are going to try and stick with and promote the use of JSON as the preferred format of responses unless otherwise noted.

* Response bodies

For a long time we have been returning responses with data that is often discarded because of its non-useful nature. Most of which resided in the meta section of the response body. This eats up bandwidth at no benefit to our API users. Once published, we can not remove things from the API without breaking application using those features. Going forward, the new style of responses will essentially be what the "results" field contained a.k.a, the data that you actually want to work with. So what about the useful data that went into the meta section of responses? Useful meta information is now encoded as HTTP headers: a better home for meta information about a response.

* Response body items

One of the best additions to the v2 apis was the introduction of the fields parameter which adds the ability to extend API with extra fields after it has been published with optional fields which may require extra resource usage but providing more useful data at the same time. This at time created some conflicts in terms of response body design. For instance, if a published method contained a reference to a member with a member_id field and we later wanted to extend the member data, a member photo perhaps, instead of being able to add the photo url to a member object we had to add that field at the same level of member_id. This was less than ideal in most cases and polluted namespaces. In the design of the three new group discussion APIs we made a conscious decision that references to other objects should, as much as possible, be represented as objects and not {object}_id fields. That way, we can more easily and consistently extend them in the future as unnecessary. This also helps naming consistency for documentation across methods.

* So what can you expect going forward?

These three new methods were developed under a newer infrastructure than previous methods. This infrastructure may still be missing some features available in v1 and v2 methods. Let us know if you find something missing that you missing or would like.

All existing methods aren't going away any time soon. While you may have noticed we have started deprecating some version 1 methods in favor of their more performant version 2 counter parts. We are not announcing the removal of any methods yet. You can even expect a few more additions to the version 2 API's which were being developed at the same time as the new infrastructure for version three was being written.

As always, we have a pipeline of newer API's and added features to existing API's. We read every one of your requests and complaints and try to address them the best we can with what API resources we have. We will announce those as they become available.