forked from rackerlabs/reddwarf
/
cdb-mgmt-devguide.xml
1276 lines (1252 loc) · 63.3 KB
/
cdb-mgmt-devguide.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book [
<!-- Some useful entities borrowed from HTML -->
<!ENTITY ndash "–">
<!ENTITY mdash "—">
<!ENTITY hellip "…">
<!-- Useful for describing APIs -->
<!ENTITY GET '<command xmlns="http://docbook.org/ns/docbook">GET</command>'>
<!ENTITY PUT '<command xmlns="http://docbook.org/ns/docbook">PUT</command>'>
<!ENTITY POST '<command xmlns="http://docbook.org/ns/docbook">POST</command>'>
<!ENTITY DELETE '<command xmlns="http://docbook.org/ns/docbook">DELETE</command>'>
<!ENTITY CHECK '<inlinemediaobject xmlns="http://docbook.org/ns/docbook">
<imageobject>
<imagedata fileref="img/Check_mark_23x20_02.svg"
format="SVG" scale="60"/>
</imageobject>
</inlinemediaobject>'>
<!ENTITY ARROW '<inlinemediaobject xmlns="http://docbook.org/ns/docbook">
<imageobject>
<imagedata fileref="img/Arrow_east.svg"
format="SVG" scale="60"/>
</imageobject>
</inlinemediaobject>'>
]>
<book xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:m="http://www.w3.org/1998/Math/MathML"
xmlns:html="http://www.w3.org/1999/xhtml"
xml:id="cdb-devguide"
version="5.0">
<?rax status.bar.text="Early Access"?>
<?rax title.font.size="35px" subtitle.font.size="20px"?>
<title>Rackspace Cloud Database Developer Guide for Service Management</title>
<?rax status.bar.text="RAX INTERNAL"?>
<titleabbrev>Rackspace Cloud Database Management Developer Guide</titleabbrev>
<info>
<author>
<personname>
<firstname/>
<surname/>
</personname>
<affiliation>
<orgname>Rackspace Cloud</orgname>
</affiliation>
</author>
<copyright>
<year>2011</year>
<year>2012</year>
<holder>Rackspace US, Inc.</holder>
</copyright>
<releaseinfo>API v1.0 EAP</releaseinfo>
<productname>Rackspace Cloud Database</productname>
<pubdate>2012-04-06</pubdate>
<legalnotice role="rs-api">
<annotation>
<remark>Copyright details are filled in by the template.</remark>
</annotation>
</legalnotice>
<abstract>
<para>This document is intended for software developers
interested in developing service management
applications using the Rackspace Cloud Database
Application Programming Interface
(<abbrev>API</abbrev>). </para>
</abstract>
<revhistory>
<revision>
<date>2012-04-06</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Added new section <xref
linkend="Service_Access_Endpoints-d1e753"
/>.</para>
</listitem>
<listitem>
<para>Added new section <xref
linkend="Host_Information"
/>.</para>
</listitem>
<listitem>
<para>Added new section <xref
linkend="Management_Instances_Actions"
/>.</para>
</listitem>
<listitem>
<para>Updated response examples for List
Database Instance Status and Details
(see <xref
linkend="Database_Instance_Management"
/>).</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2012-01-26</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Updated doc for bug fixes in
code.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2011-01-16</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Updated xml examples to remove extra
white space.</para>
</listitem>
<listitem>
<para>Added <xref
linkend="Root_Flag"/>.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2011-01-11</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Initial draft.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
</revhistory>
<cover>
<para>this is a placeholder for the front cover</para>
</cover>
<cover>
<para>this is a placeholder for the back cover</para>
</cover>
</info>
<chapter xml:id="overview">
<title>Overview</title>
<para>Rackspace Cloud Database is a database available to
Rackspace Cloud customers. Interactions with Cloud
Database occur programmatically via the Cloud Database API
as described in this <citetitle>Cloud Database Developer
Guide for Service Management</citetitle>.</para>
<remark>Writer: need to synch up Overview section with
marketing blurb for web. These should be
consistent.</remark>
<remark>Writer: need to check with Daniel for correct product
name once we have settled on that name; then get product
name modified throughout entire manual .</remark>
<para>The API operations described in this manual relate to
support of Cloud Database service activities on behalf of
a specific customer. The scope of these operations is
narrow, relating to the needs of a single customer. A
customer might directly request these operations, however
only Rackers are authorized to perform them.</para>
<para security="writeronly">The following figure shows an
overview of Cloud Database Infrastructure: <informalfigure>
<mediaobject>
<imageobject role="fo">
<imagedata
fileref="images/Cloud_DB_Infographic-1.svg"
contentwidth="6in"/>
</imageobject>
<imageobject role="html">
<imagedata
fileref="images/Cloud_DB_Infographic-1.png"
/>
</imageobject>
</mediaobject>
</informalfigure>
</para>
<remark>Writer: need to get architecture diagram for DBaaS.
Daniel emailed 11/17 that he would work on this during the
Private Beta and have it done for the Public
Beta.</remark>
<para security="writeronly">We welcome feedback, comments, and bug reports at <link
xlink:href="http://feedback.rackspacecloud.com"
>http://feedback.rackspacecloud.com</link>.</para>
<remark>Writer: check whether following statement should be
added back in for public (not private) beta: Issues and
bug reports can be directed to your support team via
ticket, chat, email, or phone.</remark>
<section xml:id="Intended_Audience-d1e122">
<title>Intended Audience</title>
<para>Two APIs provide access to Rackspace Cloud Database: </para>
<itemizedlist spacing="compact">
<listitem>
<para>The <emphasis>management</emphasis> API,
available only to developers, Support
personnel, and Operations administrators
within Rackspace, depending on the granted
LDAP roles/permissions, is the subject of this
document.</para>
</listitem>
<listitem>
<para>The <emphasis>public</emphasis> API,
available to developers within Rackspace and
Rackspace customers, is the subject of a
companion document, the <citetitle>Cloud
Database Developer
Guide</citetitle>.</para>
</listitem>
</itemizedlist>
<para>To use the information provided here, you should
first have a general understanding of the Database
service. You should also be familiar with: </para>
<itemizedlist spacing="compact">
<listitem>
<para>Database terminology</para>
</listitem>
<listitem>
<para>ReSTful web services</para>
</listitem>
<listitem>
<para>HTTP/1.1 conventions</para>
</listitem>
<listitem>
<para>JSON and/or XML data serialization
formats</para>
</listitem>
<listitem security="writeronly">
<para>ATOM Syndication Format</para>
</listitem>
</itemizedlist>
</section>
<?hard-pagebreak?>
<section xml:id="Document_Change_History-d1e166">
<title>Document Change History</title>
<para>This version of the Developer Guide replaces and
obsoletes all previous versions. The most recent
changes are described in the table below:</para>
<?rax revhistory?>
</section>
<section xml:id="Additional_Resources-d1e532">
<title>Additional Resources</title>
<para>Descriptive information about Cloud Database is also
published in its Web Application Description Language
(WADL) and XML Schema Definition (XSD). You are
welcome to read this information here:</para>
<itemizedlist>
<listitem>
<para>The WADL is <link
xlink:href="http://docs.rackspace.com/cdb/api/v1.0/management.wadl"
/>.</para>
</listitem>
<listitem>
<para>The XSD is <link
xlink:href="http://docs.rackspace.com/cdb/api/v1.0/xsd/management.xsd"/>. </para>
</listitem>
</itemizedlist>
<para>You can download the most current versions of other
API-related documents from <link
xlink:href="http://docs.rackspace.com/api/"
>http://docs.rackspace.com/api/</link>. </para>
<para>For information about getting started using Cloud
Database and Cloud Servers, refer to
<citetitle>Getting Started with Rackspace Cloud
Database and Servers</citetitle>.</para>
<para>For information about Rackspace Cloud products,
refer to <link
xlink:href="http://www.rackspace.com/cloud/"
>http://www.rackspace.com/cloud</link>. This site
also offers links to Rackspace's official support
channels, including knowledge base articles, forums,
phone, chat, and email. </para>
<para>For issues using the Cloud Database API, please send
email to the beta support list:
<email>clouddb_beta@rackspace.com</email>.</para>
<para>You can also follow Rackspace updates and
announcements via twitter at <link
xlink:href="http://www.twitter.com/rackspace"
>http://www.twitter.com/rackspace</link>. </para>
<para>This API uses standard HTTP 1.1 response codes as
documented at <link
xlink:href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html"
>http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html</link>.
</para>
</section>
</chapter>
<chapter xml:id="Concepts-d1e563">
<title>Concepts</title>
<?dbhtml stop-chunking?>
<para> To use the Cloud Database API effectively, you should
understand several key concepts: </para>
<remark>Reviewer: Daniel Morris is asking Daniel Salinas to
do an initial write-up of this chapter.</remark>
<section xml:id="DatabaseInstance-d1e588">
<title>Database Instance</title>
<para>A database instance is an isolated MySQL instance in
a single tenant environment on a shared physical host
machine.</para>
<remark security="writeronly">Writer: once we support
MSSQL, we need to describe here what is used for MSSQL
in place of database instance.</remark>
</section>
<section xml:id="Database">
<title>Database</title>
<para>A MySQL database within a database instance.</para>
<remark security="writeronly">Writer: once we support
MSSQL, we need to modify the wording here, such as:
The actual database, whether it is in MySQL or
MSSQL.</remark>
</section>
<section xml:id="Flavor">
<title>Flavor</title>
<para>A flavor is an available hardware configuration for
a database instance. Each flavor has a unique
combination of memory capacity and priority for CPU
time.</para>
</section>
<section xml:id="Volume">
<title>Volume</title>
<para>A volume is user-specified storage that contains the
MySQL data directory. Volumes are automatically
provisioned on dedicated Internet Small Computer
System Interface (iSCSI) storage area networks (SAN)
that provide for increased performance, scalability,
availability and manageability. Applications with high
I/O demands are performance optimized and data is
protected through both local and network RAID-10.
Additionally, network RAID provides synchronous
replication of volumes with automatic failover and
load balancing across available storage
clusters.</para>
</section>
</chapter>
<chapter xml:id="General_API_Information-d1e633">
<title>General API Information</title>
<para> The Cloud Database Management API is implemented using
a ReSTful web service interface. Most functions of the
customer-facing Cloud Database API may be accessed on
behalf of a customer. The Cloud Database Management API
also extends this functionality to include operations for
managing features of the public API <remark>as well as
additional data fields not available to
customers</remark>.</para>
<section xml:id="Authentication-d1e647">
<title>Authentication</title>
<para>Every ReST request against the Cloud Database
Management API requires that the caller be
authenticated with HTTP Basic Auth using LDAP. </para>
<note>
<para>Not all Rackspace employees will have access to
the Cloud Database Management API. If you cannot
access the service and feel that this is in error,
please contact your supervisor and have the
appropriate LDAP roles/permissions added. </para>
</note>
</section>
<section xml:id="Service_Access_Endpoints-d1e753">
<title>Service Access</title>
<para>The Database Service is a regionalized service. The
user of the service is therefore responsible for
appropriate replication, caching, and overall
maintenance of Cloud Database data across regional
boundaries to other Cloud Database servers.</para>
<?rax-fo keep-with-next?>
<para>Replace the sample account ID number,
<parameter>1234</parameter>, as shown in the URLs
in this guide, with your actual account number
returned as part of the authentication service
response.</para>
<para>You will find the actual account number after the
final '/' in the <code>publicURL</code> field returned
by the authentication response. In the following
example, you can see from the <code>publicURL</code>
field for <code>cloudServers</code>
(publicURL="https://servers.api.rackspacecloud.com/v1.0/322781")
that the account number is 322781.</para>
</section>
<section xml:id="Request_Response_Types-d1e503">
<title>Request/Response Types</title>
<para> The Cloud Database API supports both the JSON and
XML data serialization formats. The request format is
specified using the <code>Content-Type</code> header
and is <emphasis>required</emphasis> for calls that
have a request body. The response format can be
specified in requests either by using the
<code>Accept</code> header or by adding an
<code>.xml</code> or <code>.json</code> extension
to the request URI. Note that it is possible for a
response to be serialized using a format different
from the request. If no response format is specified,
JSON is the default. If conflicting formats are
specified using both an <code>Accept</code> header and
a query extension, the query extension takes
precedence.</para>
<para security="writeronly">Some operations support an Atom representation that
can be used to efficiently determine when the state of
services has changed. </para>
<remark>Reviewer: the previous sentence will be hidden
for the Private Beta, since it does not appear that
Atom will be supported yet. Correct?</remark>
<table rules="all">
<caption>Response Formats</caption>
<?dbfo keep-together="always"?>
<thead>
<tr align="center">
<td>Format</td>
<td>Accept Header</td>
<td>Query Extension</td>
<td>Default</td>
</tr>
</thead>
<tbody>
<tr>
<td>JSON</td>
<td>application/json</td>
<td>.json</td>
<td>Yes</td>
</tr>
<tr>
<td>XML</td>
<td>application/xml</td>
<td>.xml</td>
<td>No</td>
</tr>
<tr security="writeronly">
<td>ATOM</td>
<td>application/atom+xml</td>
<td>.atom</td>
<td>No</td>
</tr>
</tbody>
</table>
<remark>Reviewer: the ATOM row in the table above will be
hidden for the Private Beta, since it does not appear
that Atom will be supported yet. Correct?</remark>
<para>In the request example below, notice that
<parameter>Content-Type</parameter> is set to
<parameter>application/json</parameter>, but
<parameter>application/xml</parameter> is
requested via the <parameter>Accept</parameter>
header:</para>
<example xml:id="request_with_headers_json">
<title>Request with Headers: JSON</title>
<?dbfo keep-together="always"?>
<programlisting language="xml"><xi:include href="samples/db-request-types.json" parse="text"><xi:fallback>Missing code sample!<?rax fail?></xi:fallback></xi:include></programlisting>
</example>
<para><?rax-fo keep-with-next?>Therefore an XML response format is returned:</para>
<example>
<title>Response with Headers: XML</title>
<?dbfo keep-together="always"?>
<programlisting language="xml"><xi:include href="samples/db-response-types.xml" parse="text"><xi:fallback>Missing code sample!<?rax fail?></xi:fallback></xi:include></programlisting>
</example>
</section>
<section xml:id="sync_asynch_responses" security="writeronly">
<title>Synchronous and Asynchronous Responses</title>
<remark>Reviewer: please give me the updated info for this
section. Need to replace info about callback URL,
etc.</remark>
<para> All successful &GET; requests are
<emphasis>synchronous</emphasis> calls, since they
are always retrieving (reading) existing information.
With these requests, the caller waits until the call
returns with the specified code and response body. For
an example, see XXXX.</para>
<para>&PUT;, &POST;, and &DELETE; calls are <emphasis>asynchronous</emphasis>, however,
since they may take some time to process. Therefore they return 202 ACCEPTED
responses containing information with a callback URL, which allows the progress,
status, and/or response information of the call to be retrieved at a later point in
time. The asynchronous response body will look similar to the following examples,
depending on the format requested:</para>
<example>
<title>202 ACCEPTED Response: XML</title>
<?dbfo keep-together="always"?>
<programlisting language="xml">Reviewer: need code example</programlisting>
</example>
<example>
<title>202 ACCEPTED Response: JSON</title>
<?dbfo keep-together="always"?>
<programlisting language="xml">Reviewer: need code example</programlisting>
</example>
<para>The following table shows the attributes for asynchronous responses:</para>
<table rules="all">
<caption>Attributes for Asynchronous Responses</caption>
<?dbfo keep-together="always"?>
<thead>
<tr align="center">
<td colspan="1">Attribute</td>
<td colspan="4">Description</td>
</tr>
</thead>
<tbody>
<tr>
<td colspan="1">jobId</td>
<td colspan="4">An identifier for the specific request.</td>
</tr>
<tr>
<td colspan="1">callbackUrl</td>
<td colspan="4">Resource locator for querying the status of the request.</td>
</tr>
</tbody>
</table>
<note>
<para>The status for asynchronous calls is retained for up to 24 hours.</para>
</note>
<note>
<para>If a request body does not pass initial validation or an error condition
arises, you may receive an immediate error response from the request.</para>
</note>
<para>When a request is made to the callback URL provided
and the job is still running, another
<returnvalue>202</returnvalue> ACCEPTED response
is returned with the same information as the previous
one. If the request is complete, the response will be
as if the original call returned as normal, without
waiting. For example, if a Create Database request was
issued and a 202 asynchronous response was returned,
the response from querying the callback URL for a
completed successful database creation would be a
<returnvalue>200</returnvalue> OK and contain the
information for the created database. See XXXX for a
specific example.</para>
<para>If an error occurs during the processing of the
create request, querying the callback URL will return
the details of the error, as if the original call
returned the error response. For example, if a
validation error occurs during the Create Database
request above, the response from querying the callback
URL would be a <returnvalue>400</returnvalue> BAD
REQUEST and contain details regarding the specific
validation error.</para>
<note>
<para>If the response from querying a callback URL is a
<returnvalue>404</returnvalue> NOT FOUND, the details of the error in the
response body will contain information the caller may use to determine whether
the specified job itself was not found, or if the response from the original
request was a <returnvalue>404</returnvalue> NOT FOUND. </para>
</note>
<para>The description of each &PUT;, &POST;, and &DELETE;
request identifies the response codes that can
indicate success or error for that request. For
example, see XXXX immediately below the table for a
list of the successful and error response codes for
the POST /xxxx call.</para>
</section>
<section xml:id="Content_Compression-d1e1120">
<title>Content Compression</title>
<para> Request and response body data may be encoded with gzip compression to accelerate
interactive performance of API calls and responses. This is controlled using the
<code>Accept-Encoding</code> header on the request from the client and indicated
by the <code>Content-Encoding</code> header in the server response. Unless the
header is explicitly set, encoding defaults to disabled. </para>
<table rules="all">
<caption>Encoding Headers</caption>
<?dbfo keep-together="always"?>
<thead>
<tr align="center">
<td>Header Type</td>
<td>Name</td>
<td>Value</td>
</tr>
</thead>
<tbody>
<tr>
<td>HTTP/1.1 Request</td>
<td><code>Accept-Encoding</code></td>
<td>gzip</td>
</tr>
<tr>
<td>HTTP/1.1 Response</td>
<td><code>Content-Encoding</code></td>
<td>gzip</td>
</tr>
</tbody>
</table>
</section>
<section xml:id="Persistent_Connections-d1e1187">
<title>Persistent Connections</title>
<para>
By default, the API supports persistent connections
via HTTP/1.1 keepalives. All connections will be kept
alive unless the connection header is set to close.
</para>
<para>
To prevent abuse, HTTP sessions have a timeout of 20
seconds before being closed.
</para>
<note>
<para>
The server may close the connection at any time
and clients should not rely on this behavior.
</para>
</note>
</section>
<?hard-pagebreak?>
<section xml:id="Limits-d1e1208">
<title>Limits</title>
<para>
All accounts, by default, have a preconfigured set of
thresholds (or limits) to manage capacity and prevent
abuse of the system. The system recognizes two kinds
of limits: <firstterm>rate limits</firstterm> and
<firstterm>absolute limits</firstterm>. Rate limits
are thresholds that are reset after a certain amount
of time passes. Absolute limits are fixed.
</para>
<section xml:id="Rate_Limits-d1e1222">
<title>Rate Limits</title>
<para> Rate limits are specified in terms of both a
human-readable wild-card URI and a
machine-processable regular expression. The
regular expression boundary matcher '^' takes
effect after the root URI path. For example, the
regular expression ^/v1.0/instances would match
the bolded portion of the following URI:
https://ord.databases.api.rackspacecloud.com/<emphasis
role="bold">/v1.0/instances</emphasis>. </para>
<para>The following table specifies the default rate
limits for all API operations for all &GET;,
&POST;, &PUT;, and &DELETE; calls for databases
and database instances: </para>
<table rules="all">
<caption>Default Rate Limits</caption>
<thead>
<tr align="center">
<td colspan="1">Verb</td>
<td colspan="2">URI</td>
<td colspan="2">RegEx</td>
<td colspan="1">Default</td>
</tr>
</thead>
<tbody>
<tr>
<td colspan="1">&GET; changes-since</td>
<td colspan="2">*/instances/*</td>
<td colspan="2"
>^/v\d+\.\d+/\d+/instances.*</td>
<td colspan="1">3/minute</td>
</tr>
<tr>
<td colspan="1">&POST;</td>
<td colspan="2">*/instances/*</td>
<td colspan="2"
>^/v\d+\.\d+/\d+/instances.*</td>
<td colspan="1">10/minute</td>
</tr>
<tr>
<td colspan="1">&POST; instances</td>
<td colspan="2">*/instances/*</td>
<td colspan="2"
>^/v\d+\.\d+/\d+/instances.*</td>
<td colspan="1">50/day</td>
</tr>
<tr>
<td colspan="1">&PUT;</td>
<td colspan="2">*/instances/*</td>
<td colspan="2"
>^/v\d+\.\d+/\d+/instances.*</td>
<td colspan="1">10/minute</td>
</tr>
<tr>
<td colspan="1">&DELETE;</td>
<td colspan="2">*/instances/*</td>
<td colspan="2"
>^/v\d+\.\d+/\d+/instances.*</td>
<td colspan="1">100/minute</td>
</tr>
</tbody>
</table>
<para> Rate limits are applied in order relative to the
verb, going from least to most specific. For
example, although the threshold for &POST; to
/v1.0/* is 10 per minute, one cannot &POST; to
/v1.0/* more than 50 times within a single day. </para>
<para> If you exceed the thresholds established for
your account, a <errorcode>413 (Rate
Control)</errorcode> HTTP response will be
returned with a <code>Retry-After</code> header to
notify the client when it can attempt to try
again. </para>
</section>
<section xml:id="Absolute_Limits-d1e1397">
<title>Absolute Limits</title>
<remark>Reviewer: Need to update this entire section.
Please give me your updates.</remark>
<para>Refer to the following table for the absolute
limits that are set.</para>
<table rules="all">
<caption>Absolute Limits</caption>
<thead>
<tr>
<td colspan="1">Name</td>
<td colspan="3">Description</td>
<td colspan="1">Limit</td>
</tr>
</thead>
<tbody>
<tr>
<td colspan="1">Instances</td>
<td colspan="3">Maximum number of instances allowed
for your account</td>
<td colspan="1">3</td>
</tr>
<tr>
<td colspan="1">Volume Size</td>
<td colspan="3">Maximum volume size per
instance in gigabytes (GB) for your
account</td>
<td colspan="1">10</td>
</tr>
</tbody>
</table>
</section>
</section>
<section xml:id="datetimeformat">
<title>Date/Time Format</title>
<para> The Database Service uses an ISO-8601 compliant
date format for the display and consumption of
date/time values. </para>
<example>
<title>DB Service Date/Time Format</title>
<programlisting>yyyy-MM-dd'T'HH:mm:ss.SSSZ</programlisting>
<para>See the table below for a description of the date/time format codes.</para>
<para>May 19th, 2011 at 8:07:08 AM, GMT-5 would have the following
format:</para>
<programlisting>2011-05-19T08:07:08-05:00</programlisting>
</example>
<table rules="all">
<caption>Explanation of Date/Time Format Codes</caption>
<thead>
<tr>
<td>Code</td>
<td>Description</td>
</tr>
</thead>
<tbody>
<tr>
<td>yyyy</td>
<td>Four digit year</td>
</tr>
<tr>
<td>MM</td>
<td>Two digit month</td>
</tr>
<tr>
<td>dd</td>
<td>Two digit day of month</td>
</tr>
<tr>
<td>T</td>
<td>Separator for date/time</td>
</tr>
<tr>
<td>HH</td>
<td>Two digit hour of day (00-23)</td>
</tr>
<tr>
<td>mm</td>
<td>Two digit minutes of hour</td>
</tr>
<tr>
<td>ss</td>
<td>Two digit seconds of the minute</td>
</tr>
<tr>
<td>SSS</td>
<td>Three digit milliseconds of the second</td>
</tr>
<tr>
<td>Z</td>
<td>RFC-822 timezone</td>
</tr>
</tbody>
</table>
</section>
<section xml:id="pagination" security="writeronly">
<title>Pagination</title>
<remark>Reviewer: please review and give me your updates
for this section. Dev needs to determine which API
calls support pagination and then supply examples. I
have hidden this entire section for now, since we do
not believe that it will be supported for Private
Beta. Correct?</remark>
<para>To reduce load on the service, list operations will
return a maximum of 100 items at a time. This is
referred to as <emphasis>pagination</emphasis>.</para>
<para> Pagination is the ability to limit the size of the returned data as well as
retrieve a specified subset of a large data set. Pagination has two key concepts:
limit and offset. <emphasis>Limit</emphasis> is the restriction on the maximum
number of items for that type that can be returned. <emphasis>Offset</emphasis> is
the starting point for the return data. For example, an offset of 50 specifies that
the items that are returned should start with item number 51 (since the numbering is
one-based) in the collection. </para>
<para>It is important to note that offset <emphasis>must</emphasis> be a multiple of the
limit (or zero), otherwise a Bad Request Exception will be thrown. Both limit and
offset are specified via request parameters on the URI. The parameters are named
<code>limit</code> and <code>offset</code> respectively, and both apply only to
&GET; calls. If unspecified, they default to <code>limit=100</code> and
<code>offset=0</code>. See the examples that follow.</para>
<example>
<title>Examples of Limits and Offsets for Paging Calls</title>
<?dbfo keep-together="always"?>
<programlisting language="xml">Reviewer: Need code example.</programlisting>
</example>
<para>Pagination applies only to the calls listed in the following table: </para>
<remark>Reviewer: need to update the table of paginated API
calls below:</remark>
<informaltable rules="all">
<thead>
<tr align="center">
<td colspan="1">Verb</td>
<td colspan="2">URI</td>
<td colspan="3">Description</td>
</tr>
</thead>
<tbody>
<tr>
<td colspan="1">&GET;</td>
<td colspan="2">/URI/</td>
<td colspan="3">List all databases manageable
by the account specified. </td>
</tr>
<tr>
<td colspan="1">&GET;</td>
<td colspan="2"
>/URI/?name=<replaceable>Name</replaceable></td>
<td colspan="3">Filter databases.</td>
</tr>
<tr>
<td colspan="1">&GET;</td>
<td colspan="2"
>/URI/<replaceable>ID</replaceable></td>
<td colspan="3">List details of the specified
database.</td>
</tr>
<tr>
<td colspan="1">&GET;</td>
<td colspan="2"
>/URI/<replaceable>ID</replaceable>/xxx</td>
<td colspan="3">List details xxx.</td>
</tr>
<tr>
<td colspan="1">&GET;</td>
<td colspan="2"
>/URI/<replaceable>ID</replaceable>/yyy</td>
<td colspan="3">List details yyy.</td>
</tr>
</tbody>
</informaltable>
<para>See the following section for examples of paged List
Databases calls.</para>
<section xml:id="Pagination_Elements_and_Attributes-d1e1754">
<title>Pagination Elements and Attributes</title>
<remark>Reviewer: please review and give me your
updates for this section.</remark>
<para>For any collection in a result, there is a <code>totalEntries</code> attribute
representing the total number of entries there are for this item type. If the
number of items requested in the &GET; call is less then the total number of
items for this type, then there will be pagination links <code>previous</code>
and/or <code>next</code>, specifying how to get to the previous and/or next set
of records. </para>
<note>
<para>The <code>previous</code> and/or <code>next</code> link elements are
displayed only if there are items available in the corresponding link. See
the following examples for details.</para>
</note>
<example>
<title>List Databases Request with limit:
XML</title>
<?dbfo keep-together="always"?>
<programlisting language="xml">Reviewer: Need code example.</programlisting>
</example>
<example>
<title>List Databases Request with limit:
JSON</title>
<?dbfo keep-together="always"?>
<programlisting language="xml">Reviewer: Need code example.</programlisting>
</example>
<example>
<title>List Databases Response with totalEntries:
XML</title>
<?dbfo keep-together="always"?>
<programlisting language="xml">Reviewer: Need code example.</programlisting>
</example>
<example>
<title>List Databases Response with totalEntries:
JSON</title>
<?dbfo keep-together="always"?>
<programlisting language="xml">Reviewer: Need code example.</programlisting>
</example>
<para> In the previous two response examples, note that
<code>totalEntries=112</code> and that a link has been provided to retrieve
the next 3 results (<code>limit=3</code>) in the link element identified by the
attribute <code>rel="next"</code> (XML) or <code>"rel":"next"</code> (JSON). </para>
<para>The following example shows links to both previous and next results in the
responses, since the request specified to start with the fourth item in the
collection (<code>offset=3</code>):</para>
<example>
<title>List Databases Request with limit and
offset: XML</title>
<?dbfo keep-together="always"?>
<programlisting language="xml">Reviewer: Need code example.</programlisting>
</example>
<example>
<title>List Databases Request with limit and
offset: JSON</title>
<?dbfo keep-together="always"?>
<programlisting language="xml">Reviewer: Need code example.</programlisting>
</example>
<example>
<title>List Databases Response with Links to
previous and next Results: XML</title>
<?dbfo keep-together="always"?>
<programlisting language="xml">Reviewer: Need code example.</programlisting>
</example>
<example>
<title>List Databases Response with Links to
previous and next Results: JSON</title>
<?dbfo keep-together="always"?>
<programlisting language="xml">Reviewer: Need code example.</programlisting>
</example>
<para>
<?rax-fo keep-with-next?> In the previous two response examples, note that
<code>totalEntries=112</code> and two links have been provided to:<itemizedlist>
<listitem>
<para>Retrieve the next 3 results (<code>limit=3</code>) via the link
element identified by the attribute <code>rel="next"</code> (XML) or
<code>"rel":"next"</code> (JSON)</para>
</listitem>
<listitem>
<para>Retrieve the previous 3 results via the link element identified by
the attribute <code>rel="previous"</code> (XML) or
<code>"rel":"previous"</code> (JSON) </para>
</listitem>
</itemizedlist></para>
</section>
</section>
<section xml:id="efficient_polling_changes_since_parm" security="writeronly">
<title>Efficient Polling with the
<parameter>Changes-Since</parameter>
Parameter</title>
<remark>Reviewer: I have hidden this section, since it
does not appear that it will be supported for Private
Beta. Correct?</remark>
<para> The ReST API allows you to poll for the status of
certain operations by performing a &GET; on various
URIs. Rather than re-downloading and re-parsing the
full status at each polling interval, your ReST client
may use the <parameter>changes-since</parameter>
parameter to check for changes since a previous
request. The <parameter>changes-since</parameter> time
is specified as <link
xlink:href="http://en.wikipedia.org/wiki/Unix_time"
>Unix time</link> (the number of seconds since
January 1, 1970, 00:00:00 UTC, not counting leap
seconds). If nothing has changed since the
<parameter>changes-since</parameter> time, a
<returnvalue>304 (Not Modified)</returnvalue>
response will be returned. If data has changed, only
the items changed since the specified time will be
returned in the response. </para>
<remark>Reviewer: does the following sentence apply, and
should it be included?</remark>
<para>For example, performing a &GET; against
https://api.servers.rackspacecloud.com/v1.0/224532/servers?<parameter>changes-since</parameter>=1244012982
would list all servers that have changed since Wed, 03
Jun 2009 07:09:42 UTC. </para>
</section>
<section xml:id="DB_faults">
<title>Faults</title>
<remark>Reviewer: need to update this section as needed
for Cloud Database.</remark>
<para> When an error occurs, the Database Service returns
a fault object containing an HTTP error response code
that denotes the type of error. In the body of the
response, the system will return additional
information about the fault. </para>
<para>The following table lists possible fault types with their associated error codes
and descriptions.</para>
<informaltable rules="all">
<thead>
<tr align="center">
<td colspan="2">Fault Type</td>
<td colspan="1">Associated Error Code</td>
<td colspan="3">Description</td>
</tr>
</thead>
<tbody>
<tr>