Які дзвінки REST PUT / POST / DELETE повинні відповідати умовно?

1. Відповідно до "Ідеології REST", що має бути органом відповідей на запити PUT / POST / DELETE?

2. Що з кодами повернення? Чи HTTP_OKдостатньо?

3. У чому причина таких конвенцій, якщо такі є?

Я знайшов хороший пост з описом відмінностей POST / PUT: POST vs PUT, але він все ще не відповідає на моє запитання.

Пробачте про невідповідність, але якщо ви робите REST через HTTP, то RFC7231 точно описує, яка поведінка очікується від GET, PUT, POST та DELETE.

Оновлення (3 липня '14):
Специфікація HTTP навмисно не визначає, що повертається з POST або DELETE. Специфікація визначає лише те, що потрібно визначити. Решта залишається за вибором виконавця.

Загалом, конвенції - "думайте, як тільки ви доставляєте веб-сторінки".

Для PUT я б повернув той самий погляд, який ви отримали, якби ви зробили GET відразу після; це призвело б до 200 (ну якщо припустити, що візуалізація є успішною). Для POST я б переспрямував на створений ресурс (якщо припустити, що ви робите операцію створення; якщо ні, просто поверніть результати); код для успішного створення - це 201, який насправді є єдиним кодом HTTP для переспрямування, що не входить у діапазон 300.

Я ніколи не був задоволений тим, що DELETE повинен повернути (мій код наразі створює HTTP 204 та порожній корпус у цьому випадку).

Створення ресурсу, як правило, відображається на POST, і це повинно повернути розташування нового ресурсу; наприклад, в ешафоті Rails CREATE буде переспрямовано на SHOW для новоствореного ресурсу. Цей же підхід може мати сенс для оновлення (PUT), але це менше конвенції; оновлення потрібно лише свідчити про успіх. Видалення, ймовірно, повинно вказувати і на успіх; якщо ви хотіли переадресувати, повернення СПИСОК ресурсів, мабуть, має найбільш сенс.

Успіх може бути вказаний HTTP_OK, так.

Єдине жорстке правило в тому, що я говорив вище, - це, що CREATE повинен повернути місце розташування нового ресурсу. Мені це здається нічим не мислителем; має ідеальний сенс, що клієнту потрібно буде мати доступ до нового товару.

За RFC7231 це не має значення і може бути порожнім

Як ми реалізуємо стандартне рішення json api у проекті:

post / put: виводить атрибути об'єкта як у get (фільтр поля / відносини застосовується те саме)

delete: дані містять лише null (для представлення відсутнього об'єкта)

статус для стандартного видалення: 200

Мені подобається відповідь Альфонсо Тіенди з коду статусу HTTP для оновлення та видалення?

Ось кілька порад:

УДАЛИТИ

• 200 (якщо потрібно надіслати деякі додаткові дані у відповіді) або 204 (рекомендується).

• 202 Операція видалена ще не здійснена.

• Якщо нічого не можна видалити, використовуйте 204 або 404 (операція DELETE є ідентичною, видалення вже видаленого елементу є успішною , тому ви можете повернути 204 , але це правда, що idempotent не обов'язково передбачає однакову відповідь)

Інші помилки:

• 400 Поганий запит (неправильний синтаксис або поганий запит є дивним, але можливим).
• 401 Несанкціонована помилка аутентифікації
• 403 Заборонено : помилка авторизації або недійсний ідентифікатор програми.
• 405 Не дозволено . Звичайно.
• 409 Конфлікт ресурсів можливий у складних системах.
• І 501 , 502 у разі помилок.

ПУТ

Якщо ви оновлюєте елемент колекції

• 200/204 з тих же причин, що і ВИДАЛИТИ вище.
• 202, якщо операція ще не здійснена.

Посиланий елемент не існує:

• PUT може бути 201 (якщо ви створили елемент, тому що це ваша поведінка)

• 404 Якщо ви не хочете створювати елементи через PUT.

• 400 Неправильний запит (неправильний синтаксис або поганий запит, частіше, ніж у випадку DELETE).

• 401 Несанкціонований

• 403 Заборонено : помилка аутентифікації або недійсний ідентифікатор програми.

• 405 Не дозволено . Звичайно.

• 409 Конфлікт ресурсів може бути можливим у складних системах, як у DELETE.

• 422 Unprocessable об'єкт Це допомагає відрізнити «Невірний запит» (наприклад , невірний формат XML / JSON) і неприпустимі значення поля

• І 501 , 502 у разі помилок.