forked from cocoajin/http-api-design-ZH_CN
-
Notifications
You must be signed in to change notification settings - Fork 0
/
http-api-设计指南.html
671 lines (526 loc) · 24.1 KB
/
http-api-设计指南.html
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
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
<style>
body {
font-family: Helvetica, arial, sans-serif;
font-size: 14px;
line-height: 1.6;
padding-top: 10px;
padding-bottom: 10px;
background-color: white;
padding: 30px; }
body > *:first-child {
margin-top: 0 !important; }
body > *:last-child {
margin-bottom: 0 !important; }
a {
color: #4183C4; }
a.absent {
color: #cc0000; }
a.anchor {
display: block;
padding-left: 30px;
margin-left: -30px;
cursor: pointer;
position: absolute;
top: 0;
left: 0;
bottom: 0; }
h1, h2, h3, h4, h5, h6 {
margin: 20px 0 10px;
padding: 0;
font-weight: bold;
-webkit-font-smoothing: antialiased;
cursor: text;
position: relative; }
h1:hover a.anchor, h2:hover a.anchor, h3:hover a.anchor, h4:hover a.anchor, h5:hover a.anchor, h6:hover a.anchor {
background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAA09pVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2LjE0NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNiAoMTMuMCAyMDEyMDMwNS5tLjQxNSAyMDEyLzAzLzA1OjIxOjAwOjAwKSAgKE1hY2ludG9zaCkiIHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6OUM2NjlDQjI4ODBGMTFFMTg1ODlEODNERDJBRjUwQTQiIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6OUM2NjlDQjM4ODBGMTFFMTg1ODlEODNERDJBRjUwQTQiPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDo5QzY2OUNCMDg4MEYxMUUxODU4OUQ4M0REMkFGNTBBNCIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDo5QzY2OUNCMTg4MEYxMUUxODU4OUQ4M0REMkFGNTBBNCIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PsQhXeAAAABfSURBVHjaYvz//z8DJYCRUgMYQAbAMBQIAvEqkBQWXI6sHqwHiwG70TTBxGaiWwjCTGgOUgJiF1J8wMRAIUA34B4Q76HUBelAfJYSA0CuMIEaRP8wGIkGMA54bgQIMACAmkXJi0hKJQAAAABJRU5ErkJggg==) no-repeat 10px center;
text-decoration: none; }
h1 tt, h1 code {
font-size: inherit; }
h2 tt, h2 code {
font-size: inherit; }
h3 tt, h3 code {
font-size: inherit; }
h4 tt, h4 code {
font-size: inherit; }
h5 tt, h5 code {
font-size: inherit; }
h6 tt, h6 code {
font-size: inherit; }
h1 {
font-size: 28px;
color: black; }
h2 {
font-size: 24px;
border-bottom: 1px solid #cccccc;
color: black; }
h3 {
font-size: 18px; }
h4 {
font-size: 16px; }
h5 {
font-size: 14px; }
h6 {
color: #777777;
font-size: 14px; }
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0; }
hr {
background: transparent url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAYAAAAECAYAAACtBE5DAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAyJpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMC1jMDYwIDYxLjEzNDc3NywgMjAxMC8wMi8xMi0xNzozMjowMCAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6OENDRjNBN0E2NTZBMTFFMEI3QjRBODM4NzJDMjlGNDgiIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6OENDRjNBN0I2NTZBMTFFMEI3QjRBODM4NzJDMjlGNDgiPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDo4Q0NGM0E3ODY1NkExMUUwQjdCNEE4Mzg3MkMyOUY0OCIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDo4Q0NGM0E3OTY1NkExMUUwQjdCNEE4Mzg3MkMyOUY0OCIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PqqezsUAAAAfSURBVHjaYmRABcYwBiM2QSA4y4hNEKYDQxAEAAIMAHNGAzhkPOlYAAAAAElFTkSuQmCC) repeat-x 0 0;
border: 0 none;
color: #cccccc;
height: 4px;
padding: 0;
}
body > h2:first-child {
margin-top: 0;
padding-top: 0; }
body > h1:first-child {
margin-top: 0;
padding-top: 0; }
body > h1:first-child + h2 {
margin-top: 0;
padding-top: 0; }
body > h3:first-child, body > h4:first-child, body > h5:first-child, body > h6:first-child {
margin-top: 0;
padding-top: 0; }
a:first-child h1, a:first-child h2, a:first-child h3, a:first-child h4, a:first-child h5, a:first-child h6 {
margin-top: 0;
padding-top: 0; }
h1 p, h2 p, h3 p, h4 p, h5 p, h6 p {
margin-top: 0; }
li p.first {
display: inline-block; }
li {
margin: 0; }
ul, ol {
padding-left: 30px; }
ul :first-child, ol :first-child {
margin-top: 0; }
dl {
padding: 0; }
dl dt {
font-size: 14px;
font-weight: bold;
font-style: italic;
padding: 0;
margin: 15px 0 5px; }
dl dt:first-child {
padding: 0; }
dl dt > :first-child {
margin-top: 0; }
dl dt > :last-child {
margin-bottom: 0; }
dl dd {
margin: 0 0 15px;
padding: 0 15px; }
dl dd > :first-child {
margin-top: 0; }
dl dd > :last-child {
margin-bottom: 0; }
blockquote {
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
table {
padding: 0;border-collapse: collapse; }
table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
table tr:nth-child(2n) {
background-color: #f8f8f8; }
table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
table tr th :first-child, table tr td :first-child {
margin-top: 0; }
table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
img {
max-width: 100%; }
span.frame {
display: block;
overflow: hidden; }
span.frame > span {
border: 1px solid #dddddd;
display: block;
float: left;
overflow: hidden;
margin: 13px 0 0;
padding: 7px;
width: auto; }
span.frame span img {
display: block;
float: left; }
span.frame span span {
clear: both;
color: #333333;
display: block;
padding: 5px 0 0; }
span.align-center {
display: block;
overflow: hidden;
clear: both; }
span.align-center > span {
display: block;
overflow: hidden;
margin: 13px auto 0;
text-align: center; }
span.align-center span img {
margin: 0 auto;
text-align: center; }
span.align-right {
display: block;
overflow: hidden;
clear: both; }
span.align-right > span {
display: block;
overflow: hidden;
margin: 13px 0 0;
text-align: right; }
span.align-right span img {
margin: 0;
text-align: right; }
span.float-left {
display: block;
margin-right: 13px;
overflow: hidden;
float: left; }
span.float-left span {
margin: 13px 0 0; }
span.float-right {
display: block;
margin-left: 13px;
overflow: hidden;
float: right; }
span.float-right > span {
display: block;
overflow: hidden;
margin: 13px auto 0;
text-align: right; }
code, tt {
margin: 0 2px;
padding: 0 5px;
white-space: nowrap;
border: 1px solid #eaeaea;
background-color: #f8f8f8;
border-radius: 3px; }
pre code {
margin: 0;
padding: 0;
white-space: pre;
border: none;
background: transparent; }
.highlight pre {
background-color: #f8f8f8;
border: 1px solid #cccccc;
font-size: 13px;
line-height: 19px;
overflow: auto;
padding: 6px 10px;
border-radius: 3px; }
pre {
background-color: #f8f8f8;
border: 1px solid #cccccc;
font-size: 13px;
line-height: 19px;
overflow: auto;
padding: 6px 10px;
border-radius: 3px; }
pre code, pre tt {
background-color: transparent;
border: none; }
sup {
font-size: 0.83em;
vertical-align: super;
line-height: 0;
}
* {
-webkit-print-color-adjust: exact;
}
@media screen and (min-width: 914px) {
body {
width: 854px;
margin:0 auto;
}
}
@media print {
table, pre {
page-break-inside: avoid;
}
pre {
word-wrap: break-word;
}
}
</style>
<title>HTTP API 设计指南</title>
</head>
<body>
<h1>HTTP API 设计指南</h1>
<blockquote><p>翻译自 <code>HTTP API Design Guide</code> <a href="https://github.com/interagent/http-api-design">https://github.com/interagent/http-api-design</a></p></blockquote>
<h2>前言</h2>
<p>这篇指南介绍了大量的 http + json 的api设计风格，最初摘录自heroku平台的api设计指引 <a href="https://devcenter.heroku.com/articles/platform-api-reference">Heroku 平台 API 指引</a>.</p>
<p>这篇指南除了当前那些API，同时也适用于heroku平台新集成的api,我们希望那些在heroku之外的api设计者也感兴趣！</p>
<p>我们的目标是一致性，专注业务逻辑同时避免设计上的空想，我们一直在寻找一种良好的，统一的，显而易见的API设计方式，未必只有一种方式。</p>
<p>我们假设你熟悉基本的 http+json api 设计方式，但是，不一定包含在此篇指南里面的所有内容。</p>
<h2>内容</h2>
<ul>
<li><a href="#%E8%BF%94%E5%9B%9E%E5%90%88%E9%80%82%E7%9A%84%E7%8A%B6%E6%80%81%E7%A0%81">返回合适的状态码</a></li>
<li><a href="#%E6%8F%90%E4%BE%9B%E5%85%A8%E9%83%A8%E5%8F%AF%E7%94%A8%E7%9A%84%E8%B5%84%E6%BA%90">提供全部可用的资源</a></li>
<li><a href="#%E5%9C%A8%E8%AF%B7%E6%B1%82%E7%9A%84body%E4%BD%93%E4%BD%BF%E7%94%A8JSON%E6%95%B0%E6%8D%AE">在请求的body体使用JSON数据</a></li>
<li><a href="#%E6%8F%90%E4%BE%9B%E8%B5%84%E6%BA%90%E7%9A%84%E5%94%AF%E4%B8%80%E6%A0%87%E8%AF%86">提供资源的唯一标识</a></li>
<li><a href="#%E6%8F%90%E4%BE%9B%E6%A0%87%E5%87%86%E7%9A%84%E6%97%B6%E9%97%B4%E6%88%B3">提供标准的时间戳</a></li>
<li><a href="#%E4%BD%BF%E7%94%A8ISO8601%E7%9A%84%E5%9B%BD%E9%99%85%E5%8C%96%E6%97%B6%E9%97%B4%E6%A0%BC%E5%BC%8F">使用ISO8601的国际化时间格式</a></li>
<li><a href="#%E4%BD%BF%E7%94%A8%E7%BB%9F%E4%B8%80%E7%9A%84%E8%B5%84%E6%BA%90%E8%B7%AF%E5%BE%84">使用统一的资源路径</a></li>
<li><a href="#%E8%B7%AF%E5%BE%84%E5%92%8C%E5%B1%9E%E6%80%A7%E8%A6%81%E7%94%A8%E5%B0%8F%E5%86%99%E5%AD%97%E6%AF%8D">路径和属性要用小写字母</a></li>
<li><a href="#%E5%B5%8C%E5%A5%97%E5%A4%96%E9%94%AE%E5%85%B3%E7%B3%BB">嵌套外键关系</a></li>
<li><a href="#%E6%94%AF%E6%8C%81%E6%96%B9%E4%BE%BF%E7%9A%84%E6%97%A0id%E9%97%B4%E6%8E%A5%E5%BC%95%E7%94%A8">支持方便的无id间接引用</a></li>
<li><a href="#%E6%9E%84%E5%BB%BA%E9%94%99%E8%AF%AF%E4%BF%A1%E6%81%AF">构建错误信息</a></li>
<li><a href="#%E6%94%AF%E6%8C%81Etags%E7%BC%93%E5%AD%98">支持Etags缓存</a></li>
<li><a href="#%E7%94%A8id%E6%9D%A5%E8%B7%9F%E8%B8%AA%E6%AF%8F%E6%AC%A1%E7%9A%84%E8%AF%B7%E6%B1%82">用id来跟踪每次的请求</a></li>
<li><a href="#%E6%8C%89%E8%8C%83%E5%9B%B4%E5%88%86%E9%A1%B5">按范围分页</a></li>
<li><a href="#%E6%98%BE%E7%A4%BA%E9%80%9F%E5%BA%A6%E9%99%90%E5%88%B6%E7%8A%B6%E6%80%81">显示速度限制状态</a></li>
<li><a href="#%E6%8C%87%E5%AE%9A%E5%8F%AF%E6%8E%A5%E5%8F%97%E5%A4%B4%E4%BF%A1%E6%81%AF%E7%9A%84%E7%89%88%E6%9C%AC">指定可接受头信息的版本</a></li>
<li><a href="#%E6%8F%90%E4%BE%9B%E6%9C%BA%E5%99%A8%E5%8F%AF%E8%AF%BB%E7%9A%84JSON%E6%A6%82%E8%A6%81">提供机器可读的JSON概要</a></li>
<li><a href="#%E6%8F%90%E4%BE%9B%E4%BA%BA%E7%B1%BB%E5%8F%AF%E8%AF%BB%E7%9A%84%E6%96%87%E6%A1%A3">提供人类可读的文档</a></li>
<li><a href="#%E6%8F%90%E4%BE%9B%E5%8F%AF%E6%89%A7%E8%A1%8C%E7%9A%84%E7%A4%BA%E4%BE%8B">提供可执行的示例</a></li>
<li><a href="#%E6%8F%8F%E8%BF%B0%E7%A8%B3%E5%AE%9A%E6%80%A7">描述稳定性</a></li>
<li><a href="#%E8%A6%81%E6%B1%82%E4%BC%A0%E8%BE%93%E9%80%9A%E9%81%93%E5%AE%89%E5%85%A8">要求传输通道安全</a></li>
<li><a href="#%E4%BD%BF%E7%94%A8%E5%8F%8B%E5%A5%BD%E7%9A%84JSON%E8%BE%93%E5%87%BA">使用友好的JSON输出</a></li>
</ul>
<h3>返回合适的状态码</h3>
<p>为每一次的响应返回合适的HTTP状态码. 成功的HTTP响应应该使用如下的状态码:</p>
<ul>
<li><code>200</code>: <code>GET</code>请求成功, 以及<code>DELETE</code>或
<code>PATCH</code> 同步请求完成</li>
<li><code>201</code>: <code>POST</code> 同步请求完成</li>
<li><code>202</code>: <code>POST</code>, <code>DELETE</code>, 或 <code>PATCH</code> 异步请求将要完成</li>
<li><code>206</code>: <code>GET</code> 请求成功, 这里只是一部分状态码: 更多</li>
</ul>
<p>对于用户请求的错误情况，及服务器的异常错误情况，请查阅完整的HTTP状态码<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html">HTTP response code spec</a>。</p>
<h3>提供全部可用的资源</h3>
<p>提供全部可显现的资源 (例如. 这个对象的所有属性) 不用考虑全部可能响应的状态码，总是在响应码为200或是201时返回所有可用资源, 包含 <code>PUT</code>/<code>PATCH</code> 和 <code>DELETE</code>
请求, 例如:</p>
<pre><code>$ curl -X DELETE \
https://service.com/apps/1f9b/domains/0fd4
HTTP/1.1 200 OK
Content-Type: application/json;charset=utf-8
...
{
"created_at": "2012-01-01T12:00:00Z",
"hostname": "subdomain.example.com",
"id": "01234567-89ab-cdef-0123-456789abcdef",
"updated_at": "2012-01-01T12:00:00Z"
}
</code></pre>
<p>当请求状态码为202时，不返回所有可用资源,
e.g.:</p>
<pre><code>$ curl -X DELETE \
https://service.com/apps/1f9b/dynos/05bd
HTTP/1.1 202 Accepted
Content-Type: application/json;charset=utf-8
...
{}
</code></pre>
<h3>在请求的body体使用JSON数据</h3>
<p>在 <code>PUT</code>/<code>PATCH</code>/<code>POST</code> 请求的body体使用JSON格式数据, 而不是使用 form 表单形式的数据. 这里我们使用JSON格式的body请求创建对称的格式数据, 例如.:</p>
<pre><code>$ curl -X POST https://service.com/apps \
-H "Content-Type: application/json" \
-d '{"name": "demoapp"}'
{
"id": "01234567-89ab-cdef-0123-456789abcdef",
"name": "demoapp",
"owner": {
"email": "username@example.com",
"id": "01234567-89ab-cdef-0123-456789abcdef"
},
...
}
</code></pre>
<h3>提供资源的唯一标识</h3>
<p>在默认情况给每一个资源一个<code>id</code>属性. 用此作为唯一标识除非你有更好的理由不用.不要使用那种在服务器上或是资源中不是全局唯一的标识，比如自动增长的id标识。</p>
<p>返回的唯一标识要用小写字母并加个分割线格式 <code>8-4-4-4-12</code>, 例如.:</p>
<pre><code>"id": "01234567-89ab-cdef-0123-456789abcdef"
</code></pre>
<h3>提供标准的时间戳</h3>
<p>提供默认的资源创建时间，更新时间 <code>created_at</code> and <code>updated_at</code> ,
e例如:</p>
<p><code>json
{
...
"created_at": "2012-01-01T12:00:00Z",
"updated_at": "2012-01-01T13:00:00Z",
...
}
</code></p>
<p>这些时间戳可能不适用于某些资源，这种情况下可以忽略省去。</p>
<h3>使用ISO8601的国际化时间格式</h3>
<p>在接收的返回时间数据时只使用UTC格式. 查阅ISO8601时间格式,
例如:</p>
<pre><code>"finished_at": "2012-01-01T12:00:00Z"
</code></pre>
<h3>使用统一的资源路径</h3>
<h4>资源命名</h4>
<p>使用复制形式为资源命名，而不是在系统中有争议的一个单个资源 (例如，在大多数系统中，给定的用户帐户只有一个). 这种方式保持了特定资源的统一性.</p>
<h4>形为</h4>
<p>好的末尾展现形式不许要指定特殊的资源形为，在某些情况下，指定特殊的资源的形为是必须的,用一个标准的<code>actions</code>前缀去替代他, 清楚的描述他:</p>
<pre><code>/resources/:resource/actions/:action
</code></pre>
<p>例如.</p>
<pre><code>/runs/{run_id}/actions/stop
</code></pre>
<h3>路径和属性要用小写字母</h3>
<p>使用小写字母并用<code>-</code>短线分割路径名字,并且紧跟着主机域名 e.g:</p>
<pre><code>service-api.com/users
service-api.com/app-setups
</code></pre>
<p>同样属性也要用小写字母, 但是属性名字要用下划线<code>_</code>分割，以至于这样在javaScript语言中不用输入引号。 例如.:</p>
<pre><code>service_class: "first"
</code></pre>
<h3>嵌套外键关系</h3>
<p>序列化的外键关系通常建立在一个有嵌套关系的对象之上, 例如.:</p>
<p><code>json
{
"name": "service-production",
"owner": {
"id": "5d8201b0..."
},
...
}
</code></p>
<p>而不是这样 例如:</p>
<p><code>json
{
"name": "service-production",
"owner_id": "5d8201b0...",
...
}
</code></p>
<p>这种方式尽可能的把相关联的资源信息内联在一起，而不用改变响应资源的结构,或者展示更高一级的响应区域, 例如:</p>
<p><code>json
{
"name": "service-production",
"owner": {
"id": "5d8201b0...",
"name": "Alice",
"email": "alice@heroku.com"
},
...
}
</code></p>
<h3>支持方便的无id间接引用</h3>
<p>在某些情况下，为了方便用户使用接口，在末尾提供用id标识资源,例如，一个用户想到了他在heroku平台app的名字，但是这个app的唯一标识是id,这种情况下，你想让接口通过名字和id都能访问，例如:</p>
<pre><code>$ curl https://service.com/apps/{app_id_or_name}
$ curl https://service.com/apps/97addcf0-c182
$ curl https://service.com/apps/www-prod
</code></pre>
<p>不要只接受使用名字而剔除了使用id。</p>
<h3>构建错误信息</h3>
<p>在网络请求响应错误的时候，返回统一的，结构化的错误信息。要包含一个机器可读的错误 <code>id</code>,一个人类能识别的错误信息 <code>message</code>, 根据情况可以添加一个<code>url</code> ，告诉客户端关于这个错误的更多信息以及如何去解决它。
例如:</p>
<pre><code>HTTP/1.1 429 Too Many Requests
</code></pre>
<p><code>json
{
"id": "rate_limit",
"message": "Account reached its API rate limit.",
"url": "https://docs.service.com/rate-limits"
}
</code></p>
<p>把你的错误信息格式文档化，以及这些可能的错误信息<code>id</code>s 让客户端能获取到.</p>
<h3>支持Etags缓存</h3>
<p>在所有请求响应中包含一个<code>ETag</code>头,比如，标识出返回资源的指定版本. 用户能够根据他们提供的头信息<code>If-None-Match</code>，在随后的请求中检查出那些无效的。</p>
<h3>用id来跟踪每次的请求</h3>
<p>在每一个API响应中要包含一个<code>Request-Id</code>头信息, 通常用唯一标识UUID. 如果服务器和客户端都打印出他们的<code>Request-Id</code>, 这对我们的网络请求调试和跟踪非常有帮助.</p>
<h3>按范围分页</h3>
<p>对于服务器响应的大量数据我们应该为此分页。
使用<code>Content-Range</code> 头传递分页请求的数据.这里有个例子详细的说明了请求和响应头、状态码，限制条件、排序以及分页处理：<a href="https://devcenter.heroku.com/articles/platform-api-reference#ranges">Heroku Platform API on Ranges</a>.</p>
<h3>显示速度限制状态</h3>
<p>客户端的访问速度限制可以维护服务器的良好状态，进而为其他客户端请求提供高性的服务.你可以使用<a href="http://en.wikipedia.org/wiki/Token_bucket">token bucket algorithm</a>技术量化请求限制.</p>
<p>为每一个带有<code>RateLimit-Remaining</code>响应头的请求，返回预留的请求tokens。</p>
<h3>指定可接受头信息的版本</h3>
<p>在开始的时候指定API版本，使用<code>Accepts</code>头传递版本信息,也可以是一个自定义的内容, 例如:</p>
<pre><code>Accept: application/vnd.heroku+json; version=3
</code></pre>
<p>最好不要给出一个默认的版本, 而是要求客户端明确指明他们要使用特定的版本.</p>
<h3>减少路径嵌套</h3>
<p>在一些有父路径/子路径嵌套关系的资源数据模块中, 路径可能有非常深的嵌套关系, 例如:</p>
<pre><code>/orgs/{org_id}/apps/{app_id}/dynos/{dyno_id}
</code></pre>
<p>推荐在根(root)路径下指定资源来限制路径的嵌套深度。使用嵌套指定范围的资源，例如在下面的情况下，dyno属性app范围下，app属性org范围下:</p>
<pre><code>/orgs/{org_id}
/orgs/{org_id}/apps
/apps/{app_id}
/apps/{app_id}/dynos
/dynos/{dyno_id}
</code></pre>
<h3>提供机器可读的JSON概要</h3>
<p>提供一个机器可读的概要恰当的表现你的API.使用
<a href="https://github.com/interagent/prmd">prmd</a>管理你的概要, 并且确保用<code>prmd verify</code>验证是有效的。</p>
<h3>提供人类可读的文档</h3>
<p>提供人类可读的文档让客户端开发人员可以理解你的API。</p>
<p>如果你用prmd创建了一个概要并且按上述要求描述，你可以很容易的生成所有结节使用<code>prmd doc</code>的Markdown文件。</p>
<p>除此之在详细信息的结尾，提供一个关于如下信息的API摘要:</p>
<ul>
<li>验证授权,包含获取及使用验证tokens.</li>
<li>API 稳定性及版本控制, 包含如何选择所需要的版本.</li>
<li>一般的请求和响应头信息.</li>
<li>错误信息序列格式.</li>
<li>不同语言客户端使用API的例子.</li>
</ul>
<h3>提供可执行的示例</h3>
<p>提供可执行的示例让用户可以直接在终端里面看到API的调用情况,最大程度的让这些示例可以逐字的使用，以减少用户尝试使用API的工作量。例如:</p>
<pre><code>$ export TOKEN=... # acquire from dashboard
$ curl -is https://$TOKEN@service.com/users
</code></pre>
<p>如果你使用<a href="https://github.com/interagent/prmd">prmd</a>生成Markdown文档, 你会自动获取一些示例在结点处。</p>
<h3>描述稳定性</h3>
<p>描述您的API的稳定性或是它在各种各样节点环境中的完备性和稳定性
例如. 带有 原型/开发版/产品
等标签.</p>
<p>更多关于可能的稳定性和改变管理的方式，查看 <a href="https://devcenter.heroku.com/articles/api-compatibility-policy">Heroku API compatibility policy</a></p>
<p>一旦你的API宣布产品正式版本及稳定版本时, 不要在当前API版本回退做一些不兼容的改变。如果你需要回退做一些不兼容的改变,请创建一个新的版本的API。</p>
<h3>要求传输通道安全</h3>
<p>要求在传输通道安全的情况下访问API,这点没什么可解释的了. 因为这不值得去争辩在什么时候使用传输通道安全访问API是好的，什么时候是不好的，只需要记住在访问API时，使用安全传输通道就行了。</p>
<h3>使用友好的JSON输出</h3>
<p>用户在第一次看到你的API使用情况，很可能是在命令行下使用<code>curl</code>进行的。友好的输出会让他们非常容易的理解你的API，为好开发者们的方便,打印友好的JSON输出, 例如:</p>
<p><code>json
{
"beta": false,
"email": "alice@heroku.com",
"id": "01234567-89ab-cdef-0123-456789abcdef",
"last_login": "2012-01-01T12:00:00Z",
"created_at": "2012-01-01T12:00:00Z",
"updated_at": "2012-01-01T12:00:00Z"
}
</code></p>
<p>而不是这样 例如:</p>
<p><code>json
{"beta":false,"email":"alice@heroku.com","id":"01234567-89ab-cdef-0123-456789abcdef","last_login":"2012-01-01T12:00:00Z", "created_at":"2012-01-01T12:00:00Z","updated_at":"2012-01-01T12:00:00Z"}
</code></p>
<p>记住要在每行尾部包含一个换行，这样那些使用终端测试API的输出不会被遮挡住。</p>
<p>对于大多数的API友好的响应数据输出总会有更好的表现，你可能受到过不友好打印数据API的影响(例如:非常高的流量占用) 或者是在一些客户端上不能工作 (例如：一个随意编写的程序).</p>
<h3>译者注</h3>
<ul>
<li>更新时间：<code>2014-06-11</code></li>
<li>此为本人第一篇翻译文档，翻译不好的地方，还望读者见谅.</li>
<li>如果您觉得此文档对您帮助非常大，可以慰劳一下译者，<a href="http://blog.cocoajin.org/pay.html">支付宝</a></li>
</ul>
</body>
</html>