Единственная конечная точка API плюсы и минусы - PullRequest
Новая
       19

Единственная конечная точка API плюсы и минусы

2 голосов
/ 12 апреля 2019

Я создаю API и пытаюсь выяснить, является ли спланированный подход хоть чем-то хорошим.
Этот API не является общедоступным, и он будет использоваться SPA и мобильным приложением, которое я создаю.
Так что я думаю о GraphQL-нравится дизайн, но без публикации json и с обычными методами HTTP.Примерно так для методов GET:

Пример 1 - получить пользователей с конкретными полями (_join означает объединение таблиц sql), упорядочением и лимитом:
api.com?table=users&displayFields=id,name,email,address,tel,country_join&orderBy=asc&orderColumn=name&offset=0&limit=10

Пример 2 - получить пользователейоснованный на параметрах поиска со всеми полями, порядком и лимитом:
api.com?table=users&search=John&searchFields=name,email&orderBy=asc&orderColumn=name&offset=0&limit=10

Я предполагаю, что это плохо, поскольку REST является стандартным, в противном случае я бы увидел гораздо больше примеров такого подхода.
Но почему это плохо?Мне кажется, что его проще разрабатывать и более гибким в использовании.
Является ли правильный REST API для предоставленных мною примеров проще в реализации, безопаснее, проще в использовании или кэшировании?

1 Ответ

1 голос
/ 12 апреля 2019

Основное различие между размещением переменных в URL и теле запроса:

  • длина данных, так как длина URL-адреса ограничена, а тело запроса не
  • специальные символы, которые должны быть экранированы в URL, что может привести к длинному и нечеткому URL

Это 2 плюса в пользу данных в теле запроса, но я согласен, что данные в URL намного прощедля тестирования и использования как вам не нужен инструмент клиента http, такой как curl или postman, для проверки ваших конечных точек.

REST, однако, имеет более строгие соглашения, если вы хотите полностью реализовать его:

  • используйте правильные http-запросы (get, post, patch, delete и put) для выполнения операций crud на одной конечной точке
  • в результате верните правильный http-код
  • используйте стандартный формат данных дляввод и вывод (json или XML)

Для лучшей совместимости между системами рекомендуется соблюдать REST и шаблоны проектирования микросервисов.

FoВ небольших приложениях мы можем следовать некоторым ярлыкам и не полностью соответствовать.До сих пор я интегрировал несколько сервисов и каждый раз могу сказать вам, что ни один из них не реализует стандарт REST: -)

...