https://blog.pgxn.org/tags/rest/REST2011-04-29T20:44:02ZThe PGXN MaintainersHugohttps://blog.pgxn.org/post/5049235040About the Infrastructure: PGXN API2026-10-07T16:13:48Z2011-04-29T20:44:02ZDavid E. WheelerThe second piece of the PGXN infrastructure, after PGXN Maanager, is the PGXN API Server. I’ve just finished the API documentation, which covers both the lightweight static file API provided by mirrors and the superset provided by the API server. So now seems like a good time to talk about the design of the API server and how it works.

At its core, the PGXN API server is just another mirror. It has an hourly cron job that rsyncs to the master mirror, updating the mirror. But then it iterates over the rsync log and transforms some things. Here’s what it does:

]]>The second piece of the PGXN infrastructure, after PGXN Maanager, is the PGXN API Server. I’ve just finished the API documentation, which covers both the lightweight static file API provided by mirrors and the superset provided by the API server. So now seems like a good time to talk about the design of the API server and how it works.

At its core, the PGXN API server is just another mirror. It has an hourly cron job that rsyncs to the master mirror, updating the mirror. But then it iterates over the rsync log and transforms some things. Here’s what it does:

  • Unpacks each distribution in a directory for browsing. Here, for example, is where one can browse the semver 0.2.1 sources.
  • Searches for a README file and any files recognized by Text::Markup and converts them to sanitized HTML with a table of contents. Such files can then be used to display the README on the distribution page and to display individual documentation files.
  • Merges the distribution metadata file with the latest stable release META.json generated by PGXN Manager. For example, as of this writing, the API server’s semver 0.2.1 META.json and the unversioned semver.json are identical. Effectively, this format has all the metadata from the META.json as well as a list of all releases of the distribution from the semver.json. This is useful for displaying all the data on the distribution page by fetching the data in a single API request.
  • Updates all other versions of the META.json file. For example, if you look at the semver 0.0.0 META.json, you’ll see that it includes 0.2.1 in its list of releases, even though 0.2.1 was released after 0.2.0. This allows semver 0.2.0 page on the main site to have a select list of version to choose from, including versions released later, with a single API request.
  • Adds additional metadata to the extension JSON file for all extensions in the distribution. The added data includes release dates for the list all distributions providing the extension, as well as an abstract and doc path for the latest stable release. To see the differences, compare the mirror semver.json to the API semver.json.
  • Adds an abstract for each distribution listed in the user’s JSON file and all tag JSON files. Compare, for example, the mirror theory.json to the API theory.json and the mirror data types.json to the API data types.json. This allows the user page and tag pages to include the abstract in the list of distributions released by the user or associated with a tag.
  • Adds records to a Lucy-powered full text search index.

All of this merging stuff came out of my thinking following the discussion of the PGXN API RFC. The decision to use Lucy instead of PostgreSQL’s full-text search followed rather naturally from this, as I quickly realized that there was no other driving need for a relational database behind the API at all. The only dynamic API is the search API. Everything else is just static files. And given the performance issues of in-database search, as well as the desire to have fewer outside dependencies, made the decision a natural one.

Beyond the syncing, there is a very simple web server providing the HTTP REST interface to the static JSON files and the full-text search. That’s it, really. The API server is really just another mirror on steroids. The nice thing is that it allows an interface, such as WWW::PGXN or the new PGXN client to work with either interface, just failing gracefully when API server APIs are unavailable.

If you want to learn more about the specifics of the REST API, the API documentation has all the details. Really, it’s quite comprehensive!

I actually consider the API to be 1.0-complete at this point, unlike PGXN Manager. The only thing I want to add is JSONP support for static JSON files (right now it’s only for search results) and might tweak a few things here and there, but otherwise I think it’s in pretty good shape.

Longer term, though, it might be worthwhile to add some other features to enhance the value of PGXN overall. Some ideas:

  • Distribution and/or extension ratings (reviews, Like/Dislike, stars, or something).
  • Diffs to compare changes between versions.
  • A test reporting infrastructure with result matrices (á la CPAN Testers.

But I think we need to build up some momentum on the foundation that’s in place. Have you submitted your extensions, yet?

]]>https://blog.pgxn.org/post/988613682A RESTful Directory2026-10-07T16:13:48Z2010-08-21T18:52:00ZDavid E. Wheelerdirectory structure, Aristotle Pagaltzis saw fit to bug me via email about a different approach. I couldn’t understand WTF he was talking about until today. Then it lit my brain on fire. As a result, I now think that there is a much better way to organize the metadata files for the PGXN – one that happens not to include any symbolic links (which is something that Andreas König has been flagging, via email, as a possible bottleneck).]]>Following my post outlining a possible network directory structure, Aristotle Pagaltzis saw fit to bug me via email about a different approach. I couldn’t understand WTF he was talking about until today. Then it lit my brain on fire. As a result, I now think that there is a much better way to organize the metadata files for the PGXN – one that happens not to include any symbolic links (which is something that Andreas König has been flagging, via email, as a possible bottleneck).

First, the /dist directory will be the same as before. Releases of pgTAP would be in:

dist/p/pg/pgtap/pgtap-0.23.pgz
dist/p/pg/pgtap/pgtap-0.23.json
dist/p/pg/pgtap/pgtap-0.23.readme
dist/p/pg/pgtap/pgtap-0.24.pgz
dist/p/pg/pgtap/pgtap-0.24.json
dist/p/pg/pgtap/pgtap-0.24.readme
dist/p/pg/pgtap/pgtap-0.25.pgz
dist/p/pg/pgtap/pgtap-0.25.json
dist/p/pg/pgtap/pgtap-0.25.readme

The only change is that the pgtap.json symlink is gone.

Now, the new stuff. In the root directory will be a file, index.json, that contains templates for URIs. It will look something like this:

{
    "dist":   "/dist/$a/$ab/$dist/$dist-$version.pgz",
    "readme": "/dist/$a/$ab/$dist/$dist-$version.readme",
    "meta":   "/dist/$a/$ab/$dist/$dist-$version.json",

    "by-dist":      "/by/dist/$a/$ab/$dist.json",
    "by-extension": "/by/extension/$a/$ab/$extension.json",
    "by-owner":     "/by/owner/$a/$ab/$owner.json",
    "by-manager":   "/by/manager/$a/$ab/$manager.json",
}

The PGXN client will always fetch this file before it does anything else, because the file tells it how to find stuff. The advantage here is that the client doesn’t have to know anything about how the directory is actually organized, just what the template variables might be. They are:

  • $dist: A distribution name
  • $version: A version number
  • $extension: An extension name
  • $owner: An owner’s name
  • $manager: A release manager’s name (managers are the people who upload distributions to PGXN)
  • $a: The first letter of a distribution, extension, owner, or manager name.
  • $ab: The first two letters of a distribution, extension, owner, or manager name.

I’m not thrilled about using prefix-staggering to avoid having too many files in a directory. But the truth is that this approach allows me to punt. I could also make sure the client supports, for example, $bc and $cd, so that one could stagger things differently. And then the nice thing is that I don’t have to use those at all. The templates will tell the client exactly how to construct the URIs for things, and the templates needn’t include those staggering variables if they’re not appropriate. The client won’t care because it will have no built-in knowledge of how things are organized. It will have to find out from index.json.

From the URI templates, you can now see where the other metadata will be stored. For extension names, a hypothetical pgTAP distribution with two extensions will have a JSON file for each extension:

/by/extension/p/pg/pgtap.json
/by/extension/s/sc/schematap.json

The pgtap.json file will look something like this:

"stable":   "0.25.0",
"testing":  "0.26.0b1",
"unstable": "0.30.0u",
"versions": {
    "0.26.0b1": { "dist": "pgtap", "version": "0.26.0b1", "status": "testing" },
    "0.30.0u":  { "dist": "pgtap", "version": "0.30.0u",  "status": "unstable" },
    "0.25.0":   { "dist": "pgtap", "version": "0.25.0",   "status": "stable" },
    "0.24.0":   { "dist": "pgtap", "version": "0.24.0",   "status": "stable" },
    "0.25.0":   { "dist": "pgtap", "version": "0.23.0",   "status": "stable"  }
}

Right at the top, it would always list the most recent stable, testing, and unstable version number, and then it would have a list metadata for all versions. Said metadata would include the associated distribution name, version, and release status.

Here’s how it would work. Say I ask the client to install pgtap:

PGXN> install extension pgtap

The client would first fetch /index.json, then look for the URI template for “by-extension”, which is /by/extension/$a/$ab/$extension.json. Filling in the template, it would know to request /by/extension/p/pg/pgtap.json. With that file, it would see that the most recent stable version is in the “pgtap” distribution version 0.25.0. Using the dist URI template, which is /dist/$a/$ab/$dist-$version.pgz, it would then fetch /dist/p/pg/pgtap/pgtap-0.25.0.pgz.

The advantage here is that there are no symbolic links and no knowledge of the directory structure built into clients. The client just knows to fetch /index.json and then to use the templates in that file to fetch other information. That’s the whole interface. Very RESTful.

The structure of the other /by files would be similar. For

PGXN> install dist pgtap

the client would use the “by-dist” URI template to construct the URL /by/dist/p/pg/pgtap.json. That file would have something like:

"stable":   "0.25.0",
"testing":  "0.26.0b1",
"unstable": "0.30.0u",
"versions": {
    "0.26.0b1": "testing",
    "0.30.0u":  "unstable",
    "0.25.0":   "stable",
    "0.24.0":   "stable" ,
    "0.23.0":   "stable"
}

So then the client would know that “0.25.0” was the most recent version, and use the dist URI template to request /dist/p/pg/pgtap/pgtap-0.25.0.pgz.

If The client command had been:

PGXN> readme dist pgtap

It would use the readme URI template. And the command:

PGXN> meta dist pgtap

Would use the meta URI template to fetch the metadata for the distribution.

If the client had requested a specific version:

PGXN> install dist 0.23.0

It could either use the by-dist URI template to download the list of all versions to see if 0.23.0 was valid, or just use the dist URI template to try to download the distribution itself.

And finally, the owner and manager JSON files, such as

/owner/t/th/theory.json

Would look something like:

"full_name": "David Wheeler",
"email": "theory@pgxn.org",
"uri": "https://justatheory.com",
"distributions": {
    "pgtap": [ "0.25.0", "0.24.0", "0.23.0" ]
    "pair": [ "0.2.0", "0.1.0", "0.0.5" ]
}

With that, the client can be asked to fetch metadata for a given owner name and use it to figure out what distributions and versions the the owner, um, owns. One could then fetch the metadata, readme, or distribution file for any of those distributions and versions.

Overall, I think that this is a much better solution than I outlined before. If only I could figure out something more elegant that the prefix-staggering/hashing stuff, it would be just about perfect.

Thoughts?

]]>https://blog.pgxn.org/post/954535657Thoughts on the Network Directory Structure2026-10-07T16:13:48Z2010-08-14T23:59:12ZDavid E. WheelerI’ve been thinking about the arrangement of stuff to be distributed to the mirrors. In doing so, I’ve kept three goals in mind:

  1. Allow things to scale.
  2. Try to put things in intuitive locations.
  3. Allow for metadata to be stored to act as a Web API.

The first two are a bit mutually-contradicting. Thinking scalability mainly means minimizing the chances that too many files can be put into a single directory. CPAN started out with all author directories in a single directory. Given the sheer number of CPAN contributors, this quickly got to be a bottleneck. To correct for that, they started “hashing” the first two letters of author names to create subdirectories. My CPAN directory, for example, is D/DW/DWHEELER. That doesn’t quite make for an intuitive location, but it’s not bad, and the tradeoff seems sufficient to keep things sane.

]]>I’ve been thinking about the arrangement of stuff to be distributed to the mirrors. In doing so, I’ve kept three goals in mind:

  1. Allow things to scale.
  2. Try to put things in intuitive locations.
  3. Allow for metadata to be stored to act as a Web API.

The first two are a bit mutually-contradicting. Thinking scalability mainly means minimizing the chances that too many files can be put into a single directory. CPAN started out with all author directories in a single directory. Given the sheer number of CPAN contributors, this quickly got to be a bottleneck. To correct for that, they started “hashing” the first two letters of author names to create subdirectories. My CPAN directory, for example, is D/DW/DWHEELER. That doesn’t quite make for an intuitive location, but it’s not bad, and the tradeoff seems sufficient to keep things sane.

The storage of metadata is important, too, as I plan to have the client send requests for JSON files to mirrors in order to find distributions. Basically, this came down to a naming convention, as well as a recipe for how to find metadata files for people and extensions. What I’ve come up with is three directories:

  • meta will contain PGXN metadata
  • dist will contain distributions
  • by will contain query-able JSON files

The meta directory will contain PGXN metadata (mirrors.json, timestamp, other detritus). If I ever create an index file that lists all distributions, it would go there, too. I’m not going to discuss it any further here, except to note that it already has mirrors.json, which clients will be able to use to present users with a list of mirrors to choose from.

The dist directory will be organized with directories named with “hashes” of the first two letters of distribution names. Let’s say that I’m releasing pgTAP 0.25 on PGXN. To distribute it, the management application will create the directory (if it doesn’t already exist):

dist/p/pg/pgtap/

Then, for the 0.25 release, it will add three files to that directory:

dist/p/pg/pgtap/pgtap-0.25.pgz
dist/p/pg/pgtap/pgtap-0.25.json
dist/p/pg/pgtap/pgtap-0.25.readme

The pgtap-0.25.pgz file will contain the zipped distribution ready for download. pgtap-0.25.json will contain metadata about the distribution, such as the owner’s name, the manager’s name (more on these folks below), list of included extensions, location of the .pgz and .readme, and its SHA1. pgtap-0.25.readme will of course contain the README for the distribution (if it has one).

Every release of pgTAP will have these three files, so after several releases, the pgtap directory might have these files:

dist/p/pg/pgtap/pgtap-0.23.pgz
dist/p/pg/pgtap/pgtap-0.23.json
dist/p/pg/pgtap/pgtap-0.23.readme
dist/p/pg/pgtap/pgtap-0.24.pgz
dist/p/pg/pgtap/pgtap-0.24.json
dist/p/pg/pgtap/pgtap-0.24.readme
dist/p/pg/pgtap/pgtap-0.25.pgz
dist/p/pg/pgtap/pgtap-0.25.json
dist/p/pg/pgtap/pgtap-0.25.readme
dist/p/pg/pgtap/pgtap.json

The last file there, pgtap.json, will actually be a symlink to the JSON file for latest production release of pgTAP. In this case, it would link to pgtap-0.25.json. The nice thing about this is that, if a client wants to find the information about the latest release of the pgtap distribution, all it will have to do is send an HTTP GET request for dist/p/pg/pgtap/pgtap.json to any mirror.

The by directory will also contain JSON files for clients to request. The idea is that you want to find information “by” something. To start with, there will be three subdirectories:

by/extension/
by/manager/
by/owner/

The first directory, by/extension/, will contain links to JSON files for extensions. Say that the pgTAP distribution offers two extensions to PostgreSQL named “pgtap” and “schematap”. The links would be:

by/extension/p/pg/pgtap/pgtap-0.23.json
by/extension/p/pg/pgtap/pgtap-0.24.json
by/extension/p/pg/pgtap/pgtap-0.25.json
by/extension/p/pg/pgtap/pgtap.json

Each of these will simply be symlinks pointing to the appropriate distribution files:

dist/p/pg/pgtap/pgtap-0.23.json
dist/p/pg/pgtap/pgtap-0.24.json
dist/p/pg/pgtap/pgtap-0.25.json
dist/p/pg/pgtap/pgtap.json

Yes, the last one is a symlink to a symlink. Similarly, these files for “schematap”:

by/extension/s/sc/schematap/schematap-0.23.json
by/extension/s/sc/schematap/schematap-0.24.json
by/extension/s/sc/schematap/schematap-0.25.json
by/extension/s/sc/schematap/schematap.json

Point to exactly the same files. Essentially, this is a way for extensions to point to the distributions that contain them. by/extension/s/sc/schematap/schematap.json points to dist/p/pg/pgtap/pgtap.json, which contains path to the .pgz file to download (and lots of other metadata, too).

The idea is that, whatever the name of the extension you want, the client will be able to easily find the metadata file that tells it where to find the distribution.

The by/manager and by/owner directories, on the other hand, contain JSON files with information about managers and owners and their distributions. Definitions:

An “owner” is someone who owns a distribution. This will often be the original author of an extension, but may be someone else if maintenance has been passed on. Basically, the “owner” is the person who should be contacted with bug reports and the like

A “manager” is someone who manages the release process. This is the user who will log into the PGXN management application and upload a distribution for release.

These two people will often be the same person, but not always. I’ve avoided the term “author” (the term used by CPAN) because the author of an extension may no longer maintain it. “Owner” seemed like a better choice (individual distributions are free to describe their contributors however they wish).

As the owner of a few extensions on PGXN, I’d have this file:

by/owner/t/th/theory.json

This file would contain a list of my distributions and perhaps some other information (like my full name and blog URL).

As the manager of extensions on PGXN (that is, I actually uploaded them), I would also have:

by/manager/t/th/theory.json

This file would contain a list of the distributions I’ve released on PGXN. This might be exactly the same as the list in my owner file, but may not be. Perhaps for one release of pgTAP, say 0.26, Duke Leto uploaded a release. In that case, 0.26 would probably be in my owner file, but not in my manager file: it would be in Duke’s manager file, instead.

So these are the basics of the directory structure for the networked mirrors. Note that I haven’t thought much about everything that will go into the JSON files (or whether or not they’d be versioned). That will likely depend quite a lot on what the management database ends up looking like. I’ll be working on that next.

But other than that, comments? Questions? Criticisms? Recommendations? Leave a comment and let me know!

]]>