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

http://www.meetup.com/meetup_api/docs/:urlname/boards/
http://www.meetup.com/meetup_api/docs/:urlname/boards/:bid/discussions/
http://www.meetup.com/meetup_api/docs/:urlname/boards/:bid/discussion...

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

http://www.meetup.com/meetup_api/console/?path=/:urlname/boards&:urln...

* 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.

Doug Tangren
Meetup <http://meetup.com>
API Team