- 1 What is the Services API
- 2 How to Use API Methods
- 3 POST-only APIs
- 4 Proper use of APIs
- 5 SOAP and WSDL (Web Service Description Language)
- 6 Current Services
- 7 Lists of API Parameters
- 8 Perl API examples
- 9 Python API Examples
What is the Services API
The Services API is a new set of APIs (Application Programming Interfaces) taking the place of MythXML in MythTV versions .25 and later. It is an extremely featureful set of interfaces designed to allow one to configure MythTV, access MythTV content, control your DVR, use MythTV as a service in your own applications, and otherwise make MythTV accessible to any and everyone.
The Services API uses regular HTTP POST and GET commands, and can return both JSON and XML output by setting the HTTP accepts header appropriately.
The Services API is organized into services, which are logical groupings of APIs by their function and purpose. The individual methods contained in each service are documented on the service's wiki page.
How to Use API Methods
Accessing an API is as simple as connecting to the backend's web server port (the default is 6544) at the service name's subdirectory, followed by the method and its arguments in standard HTTP format. For example, one of the simplest APIs is the SendMessage API, which is a part of the Myth service. The SendMessage API takes three arguments, but only one is necessary, the Message argument, which is the message text to be broadcast to running frontends (by default, to all of them). So, we would construct our API command this way:
This particular API has a boolean return value-- a true or false XML or JSON result that tells the application that the message was sent, or failed for some reason. A result for the above command would be:
If you mistype a parameter, the backend's web server may throw an error. If we mistype "SendMessage" as "SendMassage", the backend throws:
Because this is not a valid API. Individual APIs may also do their own sanity checking regarding required parameters, acceptable values, and other basic requirements.
So, to summarize, an API call is made using the following format:
http://BackendServerIP: + Backend Web Server Port + / + Service Name + / + API Name + ? + Arguments separated by &
Currently, all services can be called using HTTP or SOAP. Depending on the header values passed, it will send back the response data as plain XML, JSON, or SOAP wrapped XML. The header values for each are as follows:
|Header Value||Response Format|
|None of the above||XML|
It is good practice (per HTTP 1.1 standard) for those APIs which change data or trigger an action (capture card creation, settings changes, etc.) to be POST only. If you find that an API is not working, it is likely because the MythTV developers want you to think very carefully about how you use it, and it requires you to HTTP POST the data.
Proper use of APIs
While it is possible to call most if not all of the APIs from a browser, the true power of the system is exposed when they are used programmatically. You might choose to wrap the API library in a C, Java, Cocoa, or other wrapper so that all of this functionality can be used from a program of your own. You might choose to write an alternative frontend (that won't break every time the protocol or database schema changes), a web interface, or your own setup application!
SOAP and WSDL (Web Service Description Language)
Each exposed service has the ability to describe itself using WSDL. You can access it by using the following url:
If you navigate to the url using a browser that supports XSLT, you will be presented with a web page showing each method and parameters.
The real power comes when you supply the url to a web service proxy tool. It will take the WSDL and generate proxy classes that allow you to call the service methods in a way that is native to the tool/language you are using.
It has been tested to work with the following tools/languages
You can click the title of any service to see documentation on the individual APIs.
The Capture service is a series of APIs related to the capturing of recorded content. It includes methods of settings up capture devices, card inputs, and may also be expanded in the future to more directly control those interfaces.
The Channel service is a collection of methods for editing channels, adding channels, deleting channels, and modifying lineups and XMLTV services.
The Content services provides a means of serving video, music, and image content from your MythTV system's collection. Images can be dynamically scaled and served by the backend according to your request.
The DVR service allows the programmer to interface with recorded metadata in a variety of ways.
The Frontend service is actually run on Frontend systems (default port: 6547) and allows query of location, playback status, sending remote control messages, and sending popup messages, among other tasks.
The Guide service is a group of methods for accessing the program guide information for use in scheduling, and guide grid applications.
The Myth service is dedicated to MythTV specific settings, and is a series of utility APIs for influencing the way MythTV works on a low level including Storage Group configuration, settings modification and query, hardware profiling, and database backup and repair.
The Video service is used to query and modify video metadata, look up metadata, add new videos to the library, and other video-library-specific functionality.
Lists of API Parameters
A list of parameters extracted from 0.27 wsdl pages.
A list of parameters extracted from 0.28 wsdl pages, highlighting changes from 0.27.
A list of parameters extracted from 29 wsdl pages, highlighting changes from 0.28.
Discussion of how to read data via API calls from Perl, how to sieve out the information you need, how to write back to the database and a list of some pitfalls. A perl module with routines to help with this and code examples are included.
Similar to the above, but primarily a module that cares for sending/receiving API data and how to use it.