Feature: Consider Adding More Query String Filters to the Organizations API

[allella]

Most of the parts of https://data.openupstate.org/ have been 301 redirected to an equivalent on the the HG site.

I did notice that in this migration we no longer have an "Organizations API" that can be queried with this change.

It begs the question if we want / need a Laravel orgs API to replace our old REST API on the feature list?

We were using the Orgs API for the old Events API and for a Mailchimp RSS to Email campaign, which has been paused.

This Mailchimp campaign would automatically send an email to about 15 subscribers when a new organization was added to the old orgs API.

[allella]

I'm reminded that we also had a script hitting the old Orgs API to check that the organization event pages and home pages didn't return a 404.

We could certainly recreate something like that in Laravel, and may already have some of this functionality for detecting dead event URLs, but it shows the use cases we had for the old, public Orgs API.

[bogdankharchenko]

@allella we do have an org API: https://hackgreenville.com/api/v0/orgs - it is 1 to 1 with the old organizations api - maybe needs some tweaks tho

[allella]

Thanks. I forgot about that because I never documented it.

Though, I see we don't have all of the functionality of the old API, but that's fine.

The old API had the ability to filter on status, meetup service, city, and organization type.

I'm probably the only person to ever use the filters, so we can add them if there's a use-case in the future.

For now, I'll just update those old docs to note the new API and the optional tag filter.

[bogdankharchenko]

Yeah we should definitely add those filters, it should be fairly straight forward to do that.

[allella]

It's up to you. If you want to do it, then the filter names don't have to match the old API since nobody seems to be dependent on it besides my use of the current &tags=

Here's the old API query string filter list.

• city=yourcity (for spaces use %20)
• org_status= (active, inactive, on-hiatus, planned)
• event_service= (eventbrite, meetup, luma)
• organization_type= (code-school, conference, meetup, workforce)

We've already implemented &tags= so this one is done.
tag_filter_id= an integer that matches the Drupal taxonomy / tag id (ex. &tag_filter_id=1 or for multiple tags at once &tag_filter_id=1,2 )

Also, there was the ability to get the data in different formats, but I don't see that being worth effort right now and I assume we would use an Accept: header instead of a query string.

• _format= (json, hal_json, xml)