RESTful SIRI + HTTP GET parameters

[Frumin, Michael]

All,

 

Here at MTA we are somewhat rapidly approaching a decision about what web service format to use for the real-time projects we have going on, including the entirely new bus tracking and customer info system, as well as the effort to expose data publically from the existing subway tracking and in-station customer info system.  I have been pretty happy with SIRI’s ability to meet our needs so far, but I’ve run into a number of issues that I think are worth discussing on this list.  The first is discussed here, the others in following email threads.

 

The biggest reservation that people have expressed about using SIRI proper is that it requires full XML submissions over HTTP Post to request data.  We got around this in our Bus Time pilot project by taking the relevant parameters from the relevant *Request elements and shoved them up into the URL to make the whole thing work over RESTful HTTP GET requests (eg: http://bustime.mta.info/wiki/Developers/SIRIStopMonitoring). 

 

But this is totally in violation of the SIRI spec.  Can someone offer thoughts on this issue?  Is it possible to incorporate such a change into the SIRI spec?  Or are we just making huge problems?

 

We are committed to open standards, and very much want to participate in the SIRI community, but our developer feeds *have* to be HTTP GET RESTful oriented.

 

Thanks,

Mike

 

Michael Frumin

Senior Strategic Analyst

MTA Bus Customer Information Systems

2 Broadway, 27th Floor

o: 646-252-1117

c: 646-370-0388

mfr...@mtahq.org

 

[Brian Ferris]

I hate to call someone out, but I know Nick Knowles is on the mailing
list and that he has done a lot of with the SIRI standards process in
the past. Nick, can you shed any light on the SIRI standards process?

As for my two cents, I think that RESTful interface to SIRI
request-response seems like a reasonable extension. It's non-standard
true, but as long as the XML returned matches the SIRI XML schema, I
think that is 75% of the battle in terms of interoperability.

Brian

[Sean Barbeau]

I agree with Brian, re: a RESTful interface being a sensible extension
in the implementation of SIRI.

Also, a RESTful interface to SIRI is definitely preferred from a
mobile developers point-of-view, since SOAP adds a lot of XML overhead
to the communication.

We did some benchmarking in terms of mobile phone battery life for
querying a web service via SOAP or RESTful design, and there is a very
significant difference in the order of hours with the SOAP calls
quickly draining battery energy, which illustrates the extra impact of
SOAP on the radio and processor. More on these tests is available in
a paper we wrote that was published in the Transportation Research
Record journal (Figure 5, page 174):
http://trb.metapress.com/content/r27623155x844065/?p=a84b0e1814da40b2ad321445c727c946&pi=0

Additionally, many mobile app platforms don't natively include SOAP
parsers, so mobile app developers have to find 3rd party SOAP parsers
to use in their apps or code their own, which increases the amount of
time and effort required to create mobile transit apps.

It would be great if we could get a RESTful interface to SIRI included
in the official standard. I'm sure MTA isn't going to be the last
agency dealing with this issue, and using something that's officially
part of a standard makes everyone feel more comfortable.

Sean

> > mfru...@mtahq.org

[Robin V.]

Previous message was about JSON format and somehow addressed the problem of returning an originally XML payload in pseudo-standard JSON format... now, the question's about how an end user could issue a request without posting XML...

Is your problem the use of the POST http word?  the XML format to use for this POST request? or both?

If the problem is only related to XML, proposition in previous message can apply and permit replacement of "standard SIRI XML" Request by a "not too far from a standard SIRI XML to JSON converted" request.

If the problem is about the POST word, I would advocate using a mechanism that could be automated in a wrapper to transform the GET request in a real SOAP POST request.
Such transformation of GET urls in real SOAP POST requests could then be automatized and implemented in a single wrapper (standard filter of a SOAP stack) or through some kind of transparent dedicated http proxy process.

Let's take for example a concrete bustime request:

•     key - your MTA Bus Time developer API key
•     OperatorRef - the GTFS agency ID to be monitored (required).  For this pilot project, it will always be MTA NYCT
•     MonitoringRef - the GTFS stop ID of the stop to be monitored (required).  For example, 308214 for the stop at 5th Avenue and Union St towards Bay Ridge.
•     LineRef - a filter by GTFS route ID of the stop to be monitored (optional).  For this pilot project, the only valid route ID is B63.
•     DirectionRef - a filter by GTFS direction ID (optional).  Either 0 or 1.
•     StopMonitoringDetailLevel - Determines whether or not the response will include the stops ("calls" in SIRI-speak) each vehicle is going to make after it serves the selected stop (optional).  To get calls data, use value calls, otherwise use value normal (default is normal).

This request could be transformed in a real SOAP request like this:
         <ServiceRequestInfo>
            <siri:RequestorRef>MyMTABusTimeApiKey00112355</siri:RequestorRef>
         </ServiceRequestInfo>
         <Request version="1.3">
            <siri:MessageIdentifier>SIRI-REQ-0b32fffc-ff71-4d78-ab86-9e49cafa6c0c</siri:MessageIdentifier>
            <siri:MonitoringRef>308214</siri:MonitoringRef>
            <siri:OperatorRef>MTA NYCT</siri:OperatorRef>
            <siri:LineRef>B63</siri:LineRef>
            <siri:DirectionRef>0</siri:DirectionRef>
            <siri:StopMonitoringDetailLevel>normal</siri:StopMonitoringDetailLevel>
         </Request>


The idea would be to define a smart mapping process to translate from url parameters to real soap xml payloads. Until a smarter mapping ruleset is defined, let's simulate this by using camelback notation first letters. Such a payload could be converted into (each part of url is separated by a linebreak for readability):

http://<sirihost>:<siriport>/services/sm?   
sri.rr=MyMTABusTimeApiKey00112355&
r.%40v=1.3&             // equivalent of urlencoded r.@v=1.3
r.mi=SIRI-REQ-0b32fffc-ff71-4d78-ab86-9e49cafa6c0c&
r.or=MTA%20NYCT&
r.lr=B63&
r.dr=0&
r.smdl=normal

Which in a single line would looks like:

http://<sirihost>:<siriport>/services/sm?sri.rr=MyMTABusTimeApiKey00112355&r.%40v=1.3&r.mi=SIRI-REQ-0b32fffc-ff71-4d78-ab86-9e49cafa6c0c&r.or=MTA%20NYCT&r.lr=B63&r.dr=0&r.smdl=normal

This proposal suggests using 2 letter acronym of SIRI service in "resource" part of the uri (sm, gm, sx, fm, etc.). Other parameters are self explanatory (sri.rr stands for ServiceRequestInfo/RequestorRef, r.smdl stands for Request/StopMonitoringDetailLevel, etc.).

I didn't try to check for camelback acronyms uniqueness, there may be a lot of things to improve, but such a method could be easily enhanced to describe and permit a full support of the whole siri standard in an interoperable fashion with a very limited amount of work (keeping in mind that url length can also be a limited resource).

Any comments welcome.

Regards,
Robin

[Ofer Porat]

Hello

Does anyone is familiar with a transit Journey Planner system (usually a web
or smartphones end users) that is not only based on the planned time tables
(PT according to SIRI) but also holds a daily updated data (not a real time)
according to the changes made by the transit operator's fleet manager.

The interface between the Journey Planner system and the fleet management
system can be potentially done using SIRI ST service (or other protocol).

Thanks

Ofer Porat

[Christophe Duquesne]

Bonjour

Using SIRI Production Timetable is a good option, also allowing you to
only echange the modification from the planed passing times

In France we are also currently using NETPUNE (Transmodel based XML
for scheduled data, even for a single production day) and I guess
germany is using VDV452 and UK TransXChange. But we all will soon all
go to the new NeTEx CEN standard which includes a good solution for
production timetable.

NeTEx is an under construction CEN standard (CEN TC278 WG3 SG9) focus
on scheduled data exchange. It will provide a solution in number of
situations, like feeding passenger information system or exchange
between planning systems and AVMS, etc. and will also be the base for
SIRI reference data (i.e. necessary scheduled information for SIRI
exchange, knowing that current SIRI reference data services are quite
simplistic). NeTEx will be available before the end of the year.

Christophe Duquesne

[Ofer Porat]

Thanks for your helpful response.

Does it means that the central Journey Planer system are online with the
transit operators' systems exchanging daily schedule updates ?

Ofer

[deepa.r...@gmail.com]

Hello,

Is there any information on what is the planned time frame for the official release of a stable schema for NeTEx? Their website (http://www.kizoom.com/standards/netex/index.htm) says the standard is still under development .
Email to the contact listed in the website bounced back.

Any info on this would really help.

Thanks
Deepa