Overview Query http://domain.com/work/api/v1/<fmt>/<cmd>?sid=<sid>&lng=ru&param1=value1&param2= value2...

Require parameters <sid> - optional if you already passed through COOKIES Other parameters fmt - The format in which the data is returned in response to this request .. Possible values ??are: ? xml ? json cmd - name of the function you need to perform the buyout on the server and retu rn the result of its execution to the client. Any request may be present parameter "lng" with the two-letter language ("ru", "en", ...). This parameter indicates what language the server returns the error detail in response to the current request . By default, the server returns an e rror in Russian . Description All requests to the API have the form specified section 'Query'. Recommended method call : POST. All functions return either answer with their own parameters , or, in the case o f error or inability to perform the requested operation , the standard response of parameter : Standard response with an error message (example format XML) <response> <error> <code> UNKNOWN </code> <message> Unknown error </message> </error> <servertime> 1292870500 </servertime> </response> The presence of errors is considered in the presence of the response parameter < error> with nonempty parameter <code>. <code> Parameter is returned as defined aliases error, rather than numeric value s. All functions are divided into session Working Executives Task authorization functions : creating a working session to give it a unique id entifier (hereinafter - short : SID), maintaining the active session and closing session. All functions except authorization functions to create a session , only work wit hin an open session , passing the SID session HTTP COOKIE request or query param eter . Total regular work session looks like this: The authorization function is called to create a new session ( get SID and oth er parameters of the session ); performing all necessary operating and control functions ; The authorization function is called closure. Remark

Unlike API versions earlier than v1.0, no longer manufactured server conversio n. Because with this : 1. Options TIME_ZONE and TIME_SHIFT, stored in the system client API does not use directly . API in this case only provides a mechanism for storing , changing , obtaining these parameters . 2 . Times in the format UNIXTIMESTAMP ( in particular - in the EPG) is given t o the server as it is. To consider the local timezone client owes the client pro gram , by adding to the resulting time the number of seconds the client time zon e offset relative to Greenwich (GMT, UTC). Meaning time_shift, passed in the que ry returns to answer a number of seconds. 3 . If you want to take advantage of broadcasting bias back in time (time_shif t), then you need to pass this parameter directly in queries. For this you can u se it stored in the system value obtained get_settings request or ask another in teger value in the range 0 ... 24 (hours) . If the specified parameter in the qu ery you missed ( absent) , then its default value is assumed to be 0 . Example of a client program with the times API: Assume the current client time = 15:00 and 14:00 GMT = ( timezone 0100 ) . The c lient wants to see not the current program and marching 1:00 back . Let's say it started exactly at 14:00 to the client ( 13:00 GMT). To do this, the client first requests API- function / get_settings and gets stor ed on the server, the values ??of the client time zone ( 0100 ) and timeshift ( 3:00 ) . As you can see , timeshift saved not the same that we need and we can c orrect value ( 1 hour) or save or use without saving . The client then sends a request time_shift = 1. And gets EPG transmission eventu ally UNIXTIMESTAMP appropriate time = 13:00 GMT parameter time_shift = 3600 . Cl ient to see EPG in its local time , he will have to add more to this UNIXTIMESTA MP your time zone in seconds ( in our case = 3600 ) and time_shift = 3600 . It t hen converts to a string representation UNIXTIMESTAMP and get their local transm ission start time = 15:00 .