-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathAPI Design
More file actions
37 lines (28 loc) · 4.05 KB
/
Copy pathAPI Design
File metadata and controls
37 lines (28 loc) · 4.05 KB
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
API Design
Мы закончили изучение основ и теперь готовы посмотреть, как предыдущие концепции объединяются в API.
В этой главе мы обсуждаем компоненты API, разрабатывая его.
Организация данных
По оценкам National Geographic, в 2011 году американцы сделали 80 миллиардов фотографий. Имея такое
количество фотографий, вы можете представить себе разные подходы людей к их упоряжочению на своих
компьютерах. Некоторые предпочитают сбрасывать все в одну папку. Другие тщательно выстраивают
свои фотографии в иерархию папок по годам, месяцам и событиям.
Подобным образом и компании относятся к структурированию при создании своих API. Как мы
упоминали ранее, цель API - облегчить компьютерам работу с данными компании. Имея в виду простоту
использования, одна компания может решить создать единый URL-адрес для всех данных и сделать его
доступным для поиска (что-то вроде одной папки для всех ваших фотографий). Другая может
решить дать каждому фрагменту данных свой собственный URL-адрес, организованный в виде иерархии
(как с папками и подпапками для фотографии). Каждая компания выбирает лучший способ структурировать
свой API для своей конкретной ситуации, руководствуясь существующими лучшими отраслевыми практиками.
Начните с архитектурного стиля
Обсуждая API, вы можете услышать разговоры о "мыле" (SOAP) и "отдыхе" (REST) и задаться вопросом, работают ли
разработчики программного обеспечения или планируют отпуск. На самом деле это названия двух наиболее распространенных
аррхитектур для веб-API:
- SOAP (изначально бывший сокращением, Simple Object Access Protocol) - это схема взаимодействия на основе XML,
которая имеет стандартизованные структуры для запросов и ответов.
- REST, что означает "передача репрезентативного состояния" (Representational State Tranfer), представляет собой более
открытый подход, предусматривающий множество соглашений, но оставляющий многие решения на усмотрение человека,
разрабатывающего API.
На протяжении этого курса вы, возможно, заметили, что у нас есть склонность к REST API. Это предпочтение во многом
связано с невероятной скоростью принятия REST. Это не означает, что SOAP - зло; у него есть свои сильные стороны.
Однако в центре нашего обсуждения останется REST, так как это, скорее всего, именно тот API, с которым вы
столкнетесь. В остальных разделах мы рассмотрим компоненты, составляющие RST API.