Several options for tag based endpoints.

Option1.md

We can roll the new featured tag[s] into /discover

Pros: No extra HTTP requests on the client

Cons: Kind weird, especially with pagination. Larger payload sizes.

GET /disover

{
  "projects": [{ /* Projects with the featured flag set to true */ }, ...],
  "featuredTags": {
    "mozfest2015": [{ /* projects tagged mozfest2015 */ }, ...],
    "makerparty2016": [{ /* projects tagged mozfest2015 */ }, ...]
  }
}

Option2.md

New featured tag route

Pros: only one extra request, dedicated featured tag route

Cons: pagination is still strange, one extra request

GET /discover/tagged

{
  "mozfest2015": [{ /* projects tagged mozfest2015 */ }, ...],
  "makerparty2016": [{ /* projects tagged mozfest2015 */ }, ...]
}

Option3.md

route to get featured tags, route to get projects with a tag

Pros: A way to expose featured tags without fetching projects too. easier pagination

Cons: Much more HTTP Requests

GET /discover/tags

{
  tags: ["mozfest2015", "makerparty2016"]
}

GET /projects/tagged/mozfest2015

{
  projects: [{ /* projects tagged mozfest2015 */ }, ...]
}

Option 1:

Since /discover is already an app/view specific route could we just interpolate the results with projects that have featured tags? This might make pagination less weird...

eg:

{
  "projects": [{ /* Projects with the featured flag set to true or with a featured hashtag */ }, ...],
}

Option 2:

This will still require multiple requests for the Discover view because there will be different routes for projects featured by admin flag and by hashtag. Worse, we'll have to make 2 requests for each additional "page" of data.

Option 3:

Certainly seems the most traditional for an API, but yeah, the HTTP requests will be numerous.

Could we alternatively send an array of tags in JSON to /projects as a filter? This would bring it down to 2 initial requests at least. One for the featured tag list and one for each additional page of filtered results.

RE: interpolation, definitely possible, but perhaps with a toggle for enabling it in results? GET /discover?interpolate=1

Option 2 felt like the least desirable to me.

Option 3 Sounds very nice if we forego the route based params and enable query param based fetching, for multiple tags. Results could be mashed together or organized by tag, whichever serves our needs better.

I'm leaning toward 3. An initial request to a featured tags route should be really fast and making /projects more robust with some filtering options seems nice and forward thinking (query params are fine w. me).

If we find that perf is an issue, we can look at combining requests, but I wouldn't expect it to be too bad...

Option 3 seems very sensible and gives us the most flexibility.

We will need GET /projects/tagged/hashbrowns regardless of how we handle featured tags. #hashbrowns might not be featured, but they are tasty and users should be able to tap that tag when it appears in a project description to load related projects.

I think I made things confusing when I added the idea of featured tags. We should design without featured tags in mind first, and then figure out how to handle them. These are like little ads we might drop into the Discover view, but they aren't an integral feature of the system.

core functionality:

• add description with tags
• tag as link
• list of projects with tag

# something we might try: - an "advertisement" that encourages people to browse a theme and maybe contribute a project - not a core feature - might be a good idea. might be a bad idea we change or dump

Question: should client or service wrap tags with link html?

Client. Both sides will need to share a common regex... 👍