consider jsonapi

[crotwell]

It might be a bit late for this, but you might want to consider a wide instead of deep structure, along the lines of http://jsonapi.org/. Effectively this makes the json feel more like a database and less like a document, which is very useful from a client programming standpoint. And Leveraging something like jsonapi also helps greatly when writing clients as there are well thought out use patterns and libraries with common functionality that can be reused.

The basic idea is that instead of the deep document model where a Network object contains a list of Station objects, in the jsonapi model a Network contains a list of station Ids. The actual Station objects can either be side loaded as part of the same json or returned by a subsequent request by using the ID. While it is natural to think in terms of the document hierarchy model, this wider, more database like approach can make for easier coding on both the client and server side.

[CTrabant]

No too late for consideration I'd say. I'm not in favor of replacing the current, document style prototype with jsonapi, but adding jsonapi capability to the FDSN formats and services is a worthy suggestion.

The concept is interesting. It would likely take more modification of the fdsnws-station interface to support though, at least a new parameter for ID. I suspect there are hidden complexities for the data center end as well such as enumerating all of the objects that can be referred to and dealing with the constant updates safely. Possible though. Reuse of libraries is compelling for sure.

I would favor working through the document-style prototype initially, which is really just a JSON-containerized version of core metadata from StationXML. Then test the waters of JSON API?

[crotwell]

Sounds good to me. I don't oppose the document style, there is probably a need, but I would find the jsonapi style more useful for my uses.