[qrohlf]

The complexity comes in the fact that there are different data formats and rules in play for almost every single management agency's permit/reservation system on Rec.gov - the JSON responses for, say, a trailhead in National Forest in Inyo Country, CA are different from a trailhead in National Forest in Deschutes County, OR. And those are both different for the JSON response format for a trailhead in the King Range National Conservation Area. Which is different from a trailhead in any National Park. And so on.

And all of these different permit systems trigger different forms, agreements, vehicle information collection, etc. once you move to the checkout stage. It truly is a massively complex system - if not technically, then logistically, by the sheer quantity of requirements-gathering and accommodation of hundreds of different individual land management agencies' unique systems for managing user access. I've read some of the source code for the web client (last I checked, they were still publishing source maps to prod) and it's a pretty impressive feat that it works and holds together as well as it does.

As you can tell from my comment above, I'm just as incensed about the business model as you are. It is highway robbery. Taxpayers subsidized the creation of the site, and now we're being doubly ripped off as a huge portion of the profits collected are being funneled straight back into the pockets of Booz Allen (and, no doubt, also being channeled into lobbying efforts designed to maintain this monopoly through the renewal process for the Federal Lands Recreation Enhancement Act this October).

However, I don't think that unfairly diminishing the technical and organizational achievement the site represents is going to help with trying to find a solution to the economic grift that it also represents.

[iudqnolq]

> the JSON responses for, say, a trailhead in National Forest in Inyo Country, CA are different from a trailhead in National Forest in Deschutes County, OR. And those are both different for the JSON response format for a trailhead in the King Range National Conservation Area. Which is different from a trailhead in any National Park.

Are you guessing here? I don't really know what you mean by the JSON response (from who to who?).

I tried to look into whether recreation.gov has per-agency or even more granular schemas. I found a manual to the Recreation.gov agency portal that suggests the answer. Note that even though it's hosted on the usfs site it has no usfs-specific branding. The section "Adding New Inventory to Recreation.gov" doesn't describe any agency-specific options explicitly, though it does have vague manual processes that could in theory involve custom development.

https://www.fs.usda.gov/Internet/FSE_DOCUMENTS/stelprd380615...

[qrohlf]

You can browse the site and look at the network traffic in your browser's devtools. There are some radically different response structures for the various different land management agencies.

[iudqnolq]

I just did. There's a whole bunch of junk and duplication. I focused on finding the available campsites at a campground because that seems like a core feature to me. You apparently make a GET to

    https://www.recreation.gov/api/camps/availability/campground/{id}/month?start_date={date}

I tested a USFS campground in Idaho and a BLM campground in Utah. Both returned JSON in the same general shape.

USFS (Idaho): https://www.recreation.gov/api/camps/availability/campground...

  {
    "{id}": {
      "availabilities": {
        "{date}": "Available",
      },
      "campsite_id": "63045",
      "campsite_reserve_type": "Site-Specific",
      "campsite_rules": null,
      "campsite_type": "STANDARD NONELECTRIC",
      "capacity_rating": "Single",
      "loop": "LOWER",
      "max_num_people": 8,
      "min_num_people": 1,
      "quantities": {
        "{date}": 1,
      },
      "site": "012",
      "supplemental_camping": null,
      "type_of_use": "Overnight"
    }
  }

BLM (Utah): https://www.recreation.gov/api/camps/availability/campground...

  {
    "10161360": {
      "availabilities": {
        "{date}": "Not Reservable",
      },
      "campsite_id": "10161360",
      "campsite_reserve_type": "Site-Specific",
      "campsite_rules": null,
      "campsite_type": "STANDARD NONELECTRIC",
      "capacity_rating": "",
      "loop": "One",
      "max_num_people": 8,
      "min_num_people": 1,
      "quantities": {
        "date": 1,
      },
      "site": "Site 1",
      "supplemental_camping": null,
      "type_of_use": "Overnight"
    }
  }

I'll give some credit to Booz. This seems like a decent API. Plus it's nice theres no auth whatsoever. It certainly looks to me like they're using the same data model to store both examples.

This is of course just one example. There are a ton of other JSON requests in the flow of reserving one of these specific campsites, and then there are all sorts of other processes like backpacking permits.

In my personal experience I've seen two backpacking permit reservation system styles. There's one that looks like it was shoehorned into the campsite reservation model, and another where it looks like the agency gets to define a bunch of free text fields and then has a human manually review and enter into a system.

In general I get the vibe from recreation.gov that whenever there's complicated logic there's a human in the background doing the actual work. I base this on the amount of free text inputs and the fact some actions take hours to weeks.

That's it for me looking into this, but if you post an example of what you're talking about I'd be interested.

[JumpCrisscross]

> complexity comes in the fact that there are different data formats and rules in play

Fair enough. But this complexity doesn't scale with the number of applications submitted.

[asdfman123]

People in tech often think they’re the only ones solving real problems.

But there, as well as here, the actually difficult problems involve all the dumb, complicated business logic.

[ke88y]

I'm not a clueless wet-behind-the-ears engineer, and, sorry, but I don't buy it for a second. These systems are heinous cash grabs.

[asdfman123]

Nah, both of those things can be true though, to varying extents.