Эффективность API RESTful

Question

В настоящее время я создаю приложение (скажем, приложение заметок, например, приложение для веб-приложений + мобильное приложение). Я хотел использовать RESTful API здесь, поэтому я много читал об этой теме, и я обнаружил, что там много двусмысленности.

Итак, давайте начнем с самого начала. И начало в REST состоит в том, что мы должны сначала запросить/(root), затем он возвращает список путей, которые мы можем получить, и т. Д. И т. Д. Разве это не первая часть, в которой REST полностью расточительна? Вместо жестких путей мы должны получать их каждый раз, когда хотим что-то сделать. Неа.

Вторая проблема, с которой я столкнулся, - операции навалом. Как реализовать их в REST? Предположим, у пользователя не было доступа к Интернету какое-то время, сделано несколько изменений, и все они должны быть сделаны и на сервере. Итак, допустим, пользователь изменил 50 заметок, добавил 30 и удалил 20. Мы должны сделать 100 отдельных запросов сейчас. Способ сделать массовые операции был бы очень полезен - я увидел эту тему stackoverflow: Patterns for handling batch operations in REST web services?, но на самом деле я не нашел здесь ничего интересного. Все в порядке, если вы хотите сделать один тип операций на одном типе ресурсов.

Последнее, но не менее важное - получение всей коллекции предметов. При написании примера приложения, о котором я упомянул - заметки приложения, вы, вероятно, хотите получить всю коллекцию предметов (заметки, теги, доступные цвета заметок и т. Д.) Сразу. С помощью REST вам нужно сначала получить список ссылок на объекты, а затем выбрать элементы по одному. 100 заметок = более 100 запросов.

Поскольку я сейчас изучаю весь этот материал REST, я могу быть совершенно не прав в том, что я сказал здесь. Во всяком случае, чем больше я читаю об этом, тем более ужасным оно выглядит для меня. Итак, наконец, мой вопрос: где я ошибаюсь и/или как решать проблемы, о которых я говорил?

Answer 1

Все дело в Ресурсы. Ресурсы, полученные через единый интерфейс (обычно с помощью методов URI и HTTP).

1. Вы делаете не должны перемещаться по корню каждый раз. Хороший интерфейс сохраняет свои URI живыми forever (если они устарели, они должны возвращать HTTP-перемещение или подобное). Корневые пути для навигации - это часть HATEOAS, одна из которых принадлежит Рою Филдингс, определяющим архитектурные элементы REST.
2. Массовые операции - это не архитектурный стиль. В принципе ничто не останавливает вас до POST полезной нагрузки, содержащей несколько элементов для определенного ресурса. Опять же, все зависит от того, какой ресурс вы используете/предлагаете и в конечном итоге, как ваша реализация сервера обрабатывает запросы. Ваш случай из 100 запросов: я бы, вероятно, придерживался 100 запросов. Чисто писать, а накладные расходы не такие огромные.
3. Извлечение коллекции: около ресурсов, что API решает предложить. GET bookCollection/ vs GET book/1, GET/book/2 ... или даже GET book/all. Или, может быть, GET book/?includeDetails=true, чтобы вернуть все книги с такими же деталями, как GET ting их по одному.

Answer 2

Я думаю, что эта ссылка может дать вам интересные советы по проектированию службы RESTful: https://templth.wordpress.com/2014/12/15/designing-a-web-api/.

Это говорит, вот мои ответы на ваши вопросы:

• Там нет необходимости реализовать ресурс для корневого пути. С этим я думаю, что вы ссылались на HATEOS. Кроме того, ссылка на полезную нагрузку также не требуется. В противном случае вы можете использовать доступные форматы, такие как Swagger или RAML, для документирования вашего сервиса RESTful. Это покажет вашим конечным пользователям, что доступно.

• Что касается массовых операций, вы можете использовать методы POST или PATCH для реализации этого в списке ресурсов. Я думаю, что эти два ответа могут быть полезны для вас:

  • REST API - Массовое создание или обновление в одном запросе - REST API - Bulk Create or Update in single request

  • Как обновить REST Коллекция ресурсов - How to Update a REST Resource Collection

• Фактически, вы можете свободно относиться к содержимому, которое вы хотите использовать для своих методов. GET. Это означает, что корневой элемент, управляемый ресурсами (ресурс списка и ресурс элемента), может содержать его подсказки, а также зависимости. Таким образом, вы можете иметь несколько уровней в возвращаемом контенте. Например, вы можете иметь что-то подобное для элемента Book, который ссылается на список Author:

  GET /books 
  { 
      "title": "the title", 
      (...) 
      "authors": [ 
       { 
        "firstName": "first name", 
        "lastName": last name" 
       }, { 
        (...) 
       }, 
       (...)    
      ] 
  } 
  

  Вы можете заметить, что вы можете использовать параметры запроса задать RESTful службу, чтобы получить обратно ожидаемый уровень. Например, если вы хотите только книги подсказки или книги подсказки с соответствующими авторами:

  GET /books 
  { 
      "title": "the title", 
      (...) 
  } 
  
  GET /books?include=authors 
  { 
      "title": "the title", 
      (...) 
      "authors": [ 
       { 
        "firstName": "first name", 
        "lastName": last name" 
       }, { 
        (...) 
       }, 
       (...)    
      ] 
  } 
  

  Вы можете заметить, что вы можете различать два понятия здесь:

  • The внутренние данные (сложные типы, внутренние объекты): данные, которые относятся к элементу и встроены в сам элемент
  • ссылки на данные: данные, которые ссылаются и соответствуют другим элементам. В этом случае вы можете иметь ссылку или данные, встроенные в корневой элемент.

  Спецификация OData адресует такую ​​проблему своей функцией «навигационные ссылки» и ее параметром запроса expand. Смотрите следующие ссылки для получения более подробной информации:

  • http://www.odata.org/getting-started/basic-tutorial/ - Раздел «Система запросы Вариант $ развернуть»
  • https://msdn.microsoft.com/en-us/library/ff478141.aspx - Раздел «Запрос и навигация»

Надеется, что это помогает вам, Thierry