Чим відрізняється ресурс від кінцевої точки?


139

Я чув і "ресурс", і "кінцева точка", щоб посилатися на одне і те ж. Здається, ресурс - це новіший термін.

У чому різниця між ними? Чи означає "ресурс" RESTful дизайн?

Відповіді:


107

ВІДПОВІДНИЙ

Ресурс - це RESTful підмножина Endpoint .

Кінцева точка сама по собі - це місце, де можна отримати доступ до послуги:

https://www.google.com    # Serves HTML
8.8.8.8                   # Serves DNS
/services/service.asmx    # Serves an ASP.NET Web Service

Ресурс відноситься до одного або більше іменників, обслуговується, представленому в моді простору імен, тому що це легко для людей , щоб зрозуміти:

/api/users/johnny         # Look up johnny from a users collection.
/v2/books/1234            # Get book with ID 1234 in API v2 schema.

Все вищезазначене можна вважати кінцевими точками сервісу, але тільки нижня група вважатиметься ресурсами, НАЙКРАСНО кажучи. Топ-група не є виразною щодо вмісту, який вона надає.

Запит REST - це як речення, що складається з іменників (ресурсів) та дієслів (методи HTTP):

  • GET(метод) ім'я користувача johnny(ресурс).
  • DELETE(метод) книги з id 1234(ресурс).

Не ВІДБУДОВА

Кінцева точка зазвичай стосується послуги, але ресурс може означати багато речей. Ось кілька прикладів ресурсу, які залежать від контексту, в якому вони використовуються.

URL: Уніфікований "Ресурс"

  • Може бути ВІДПОВІДНИМ, але часто це не так. У цьому випадку кінцева точка майже синонімічна.

Управління ресурсами

Словник

Щось, що може вам допомогти:

Бібліотека була цінним ресурсом, і він часто використовував її.

Ресурси - це природні речовини, такі як вода та деревина, які є цінними для підтримки життя:

[pl] Земля має обмежені ресурси, і якщо ми не переробляємо їх, ми використовуємо їх.

Ресурси - це також цінні речі, такі як гроші або майно, якими ви можете скористатися, коли вам знадобляться:

[pl] Уряду немає ресурсів, щоб найняти кількість необхідних вчителів.


Мораль

Термін ресурс за визначенням має багато нюансів. Все залежить від контексту, в якому він використовується.


1
Я підозрював те саме. Ви бачили якісь посилання, які пояснюють це чи документують?
B Сім

Додано кілька посилань, які дають відчуття кожному з термінів.
cchamberlain

84

Терміни ресурс і кінцева точка часто використовуються синонімічно. Але насправді вони не означають одне і те ж.

Термін кінцева точка орієнтований на URL-адресу, яка використовується для подання запиту.
Термін ресурс орієнтований на набір даних, який повертається запитом.

Тепер до одного і того ж ресурсу часто можна отримати декілька різних кінцевих точок .
Також одна і та сама кінцева точка може повертати різні ресурси , залежно від рядка запиту.

Давайте подивимось кілька прикладів:

Різні кінцеві точки доступу до одного і того ж ресурсу

Подивіться наступні приклади різних кінцевих точок :

/api/companies/5/employees/3
/api/v2/companies/5/employees/3
/api/employees/3

Вони, очевидно, могли отримати доступ до того самого ресурсу в заданому API.

Також існуючий API можна повністю змінити. Це може призвести до появи нових кінцевих точок, які отримають доступ до тих самих старих ресурсів, використовуючи абсолютно нові та різні URL-адреси:

/api/employees/3
/new_api/staff/3

Одна кінцева точка доступу до різних ресурсів

Якщо ваша кінцева точка повертає колекцію, ви можете здійснити пошук / фільтрування / сортування за допомогою рядків запитів. Як результат, наступні URL-адреси використовують одну і ту ж кінцеву точку ( /api/companies), але вони можуть повертати різні ресурси (або колекції ресурсів , які за визначенням є самими ресурсами):

/api/companies
/api/companies?sort=name_asc
/api/companies?location=germany
/api/companies?search=siemens

4
чудово пояснено 👍🏻
мангони

1
"Внаслідок цього в наступних URL-адресах усі використовують одну і ту ж кінцеву точку (/ api / компаній), але вони можуть повертати різні ресурси." Я маю на увазі без образи, але ви справді просто вигадуєте своє тлумачення. З точки зору REST, це просто місця різних ресурсів. Частина кінцевої точки, яку ви намагалися врахувати як деяку іншу частину URL-адреси. Це тому, що ви програміст і думаєте, як його реалізувати, як фрагмент коду при одному методі дії. Уявіть, що всі ці різні URL-адреси були маршрутизовані та подані з 4-х серверів, чи всі вони однакові кінцеві точки? Зараз немає сенсу.
Люк Пуплетт

1
Причина рядків запиту не є частиною кінцевих точок, тому що кінцева точка не є частиною мови REST, ані URL. Це просто не так. Ви думаєте з точки зору кодування веб-програми для обробки. REST нічого не згадує про параметри запитів або сортування або щось подібне. Це просто ні. Якщо ви використовуєте / замовлення для повернення колекції та / замовлень? Top = 10, це просто гарні URL-адреси, це не більш-менш RESTful, ніж використання посилань на / 32knre32nj для колекції та посилання на / abcd для перших десяти замовлень. Вони просто ідентифікатори ресурсів. URL-адреси не можуть бути більш-менш RESTful, і кінцева точка - це не річ.
Люк Пуплетт

Додамо лише, що критичною частиною REST є посилання, що споживачеві потрібно не піклуватися про ідентифікатори ресурсів, тому що мені байдуже, що URL-адреса сидить за кнопкою Додати коментар тут. Коли ми перестаємо думати про кінцеві точки та гарні URL-адреси, а замість гіперпосилань, де URL-адреса є випадковою, набагато простіше розробити приємні API-файли, що базуються на робочому процесі, на меті взаємодії - я хочу шукати компанію так, щоб x - ваш API повинен був подорожувати до x, де пошук знаходиться посередині потоку до можливого стану програми.
Люк Пуплетт

Не існує високо канонічного визначення або специфікації для "кінцевої точки". Це все зводиться до технології, яку вона використовує. Справа в точці, google "Що таке кінцева точка?" і одна з найпопулярніших статей з цього питання - ця сторінка. Ми визначаємо його тут, виходячи з контексту, з яким ми бачили його. Усі приклади цієї відповіді є RESTful, хоча сама кінцева точка не обов'язково є RESTful. Дивіться SOAP.
Чемберлен

7

Можливо, моя не є чудовою відповіддю, але ось що.

Оскільки більше працюю з справжніми RESTful веб-сервісами через HTTP, я намагався відхилити людей від використання терміна кінцевої точки, оскільки він не має чіткого визначення, а замість цього використовував мову REST, що є ресурсами та ресурсами.

На мій погляд, кінцева точка - це термін TCP. Він пов'язаний з HTTP, оскільки частина URL-адреси ідентифікує сервер прослуховування.

Таким чином, ресурс не є новим терміном, я не думаю, я думаю, що кінцева точка завжди була присвоєна, і ми розуміємо це, оскільки ми обертаємось навколо REST як стиль API.

Редагувати

Я про це блогував.

https://medium.com/@lukepuplett/stop-saying-endpoints-92c19e33e819


1

Згідно https://apiblueprint.org/documentation/examples/13-named-endpoints.html це ресурс "загальне" місце зберігання даної сутності - наприклад, / замовники / 30654 / замовлення, тоді як кінцева точка - конкретна дія (Метод HTTP) над заданим ресурсом. Таким чином, один ресурс може мати кілька кінцевих точок.


1
Вибачте @Dafka, але ви помиляєтесь. Кінцева точка не має нічого спільного з дієсловом (метод HTTP, як GET, POST, PUT, DELETE, PATCH), який використовується в ньому.
Jpsy

0

Розглянемо сервер, який містить інформацію про користувачів, місії та їх бали.

  1. Користувачі та бали нагород - це ресурси
  2. Кінцева точка може стосуватися декількох ресурсів
  3. Кінцеві точки можна описати, використовуючи опис або повну або часткову URL-адресу

введіть тут опис зображення

Джерело: Кінцеві точки API проти ресурсів


-1

1. Опис ресурсу "Ресурси" позначає інформацію, повернуту API.

2. Кінцеві точки та методи Кінцеві точки вказують, як ви отримуєте доступ до ресурсу, тоді як метод вказує дозволені взаємодії (наприклад, GET, POST або DELETE) з ресурсом.

Додаткова інформація: 3. Параметри Параметри - це параметри, які ви можете передати разом із кінцевою точкою (наприклад, вказавши формат відповіді або повернуту суму) для впливу на відповідь.

4. Приклад запиту Приклад запиту включає зразок запиту з використанням кінцевої точки, показуючи деякі налаштовані параметри.

5. Приклад та схема відповіді Приклад відповіді показує зразок відповіді з прикладу запиту; схема відповіді визначає всі можливі елементи у відповіді.

Джерело- Довідкове посилання

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.