The URP: Traveller Universal REST Protocol

[robject]

Programming for interoperability between software developers is... problematic. OK, it's a nightmare. None of us have the time to write for Traveller, much less coordinate. And coordination typically gives way to committee, resulting in nothing.

There are two proven technologies which suggest a set of web-based services for Traveller programmers.

Serialized Data

There are three text-based serialization solutions currently popular. JSON is the easiest, and is native to JavaScript and ActionScript, and is supported by Perl, Python, Ruby, and other web languages.

JSON makes a good return content from a web service. It allows structured data with a minimum of fuss. The simplest JSON object is a quoted string, such as 'A788899-A'.


REST

As a programming approach, REST is a lightweight alternative to Web Services and RPC. With it, your application can implement services simply and modularly.

REST consists of URLs which form a state-encoded request. They're platform and language independent, and can run in the presence of a firewall -- they're safe.

EXAMPLES

Since our software tends to be 'builder' based and 'sector' based, I'll use those as examples.

Let's say that my base URL is http://eaglestone.pocketempires.com/rest/. I could provide services on top of it such as:

http://eaglestone.pocketempires.com/rest/uwp?sector=Deneb&hex=1925
http://eaglestone.pocketempires.com/rest/uwp?sector=Deneb&name=Deneb
http://eaglestone.pocketempires.com/rest/uwp

The third call, with no parameters, would return a random UWP according to whatever rules my service supports.

http://eaglestone.pocketempires.com/rest/word?lang=vilani&syllables=2&count=5

This call generates 5 Vilani words with 2 syllables each.

http://eaglestone.pocketempires.com/rest/upp

A random UPP.

http://eaglestone.pocketempires.com/rest/sec?sector=Deneb

See Joshua Bell's format for this one.

http://eaglestone.pocketempires.com/rest/career?service=marines&term=3&upp=nnnnnn

This one would return a structure such as:

ruleset: CT
survival: y
skills: [ pilot, jot ]
continue: y
aging: []

You get the idea.

 

[DangerousThing]

Serialized Data

There are three text-based serialization solutions currently popular. JSON is the easiest, and is native to JavaScript and ActionScript, and is supported by Perl, Python, Ruby, and other web languages.

JSON makes a good return content from a web service. It allows structured data with a minimum of fuss. The simplest JSON object is a quoted string, such as 'A788899-A'.

What advantages does JSON have over XML?

 

[coliver988]

What advantages does JSON have over XML?

generally it is smaller in terms of extra text. see http://stackoverflow.com/questions/584985/what-are-the-advantages-and-disadvantages-of-json-vs-xml-for-ajax-requests
or any search on advantages of json over xml

 

[charvolant]

What advantages does JSON have over XML?

It's pretty much directly parsable into an object for any language with dynamic objects, such as JavaScript or Python. This makes it a good transfer format for something like a web page since there's no tedious mucking about in hyperspace/parsing and binding objects.

It's fairly compact while still remaining human-readable. More so than XML, at any rate.

It has disadvantages once you cross the complexity event horizon. Unlike XML there's no standard way of binding it to a schema or providing graph-like links to other elements in the document. There are conventions that allow these things, such as JSON-LD or the Jackson bindings for Java, but it's not standardised in the way XML is.

However, most RESTful services don't cross that horizon and JSON is then very helpful.

 

[simonh]

I agree REST is flexible and very easy to implement approach for networked apps. I've implemented REST services in Python before using the Flask framework. Also while XML is more feature rich, if you're just exchanging data that expressible using simple common types such as dictionaries, lists, strings and such then JSON is much easier to work with.

 

[charvolant]

I agree REST is flexible and very easy to implement approach for networked apps. I've implemented REST services in Python before using the Flask framework. Also while XML is more feature rich, if you're just exchanging data that expressible using simple common types such as dictionaries, lists, strings and such then JSON is much easier to work with.

I tend to use the Java restlet framework. Most of what I do is destined for a tomcat server somewhere.

JSON tends to become difficult when polymorphism appears, since it's difficult to identify the type of object something is. The OGC/ISO geographical XML standards have a very strict model of Class/property/Class/property/Class/property/... for that reason; almost everything is polymorphic and substitutable. The Jackson library for Java does a pretty good job of handling polymorphism and object identity in Java/JSON but it does so by introducing all kinds of implementation-specific hacks.

My personal rules of thumb are:

• Domain modelling: Ontologies and RDF
• Exchange between loosely coupled applications: XML or NetCDF for big slabs of homogeneous data
• Exchange within a distributed application or for a RESTful service: JSON

 

[inexorabletash]

So... travellermap.com will soon support a more friendly, data-centric scheme like those above. Same data as before, but a more modern way of accessing it.

If you're interested in reviewing the URL scheme before I make it public, email me @gmail.

 

[inexorabletash]

So... travellermap.com will soon support a more friendly, data-centric scheme like those above. Same data as before, but a more modern way of accessing it.

This is now live:

http://travellermap.com/api.htm#urls

 

[charvolant]

This is now live:

http://travellermap.com/api.htm#urls

Too slow, I was. Most impressive.