Как бы вы разработали службу преобразования RESTful?

Мы создаем сервис для конвертации из одного формата в другой. Примерами преобразований являются валюты, расстояния, время, языки и т. д. В нашем случае это географические точки (например, из десятичных градусов широты/долготы в градусы-минуты-секунды широты/долготы).

Обычно ресурс RESTful имеет аналогичную объектно-ориентированную концепцию, которая сохраняется на стороне сервера и может быть CRUD (я знаю, что это только часть того, что делает что-то RESTful), но в случае простого сервиса, который преобразует вещи, это не обязательно существуют. Как можно сделать это RESTful? На данный момент у нас есть такие:

Чтобы получить список поддерживаемых форматов, можно сделать это:

GET /coordinates/formats

Что вернет список форматов, включая, например, DD и DMS (десятичные градусы и градусы-минуты-секунды).

Затем можно развернуться и выполнить преобразование следующим образом:

POST /coordinates/DD/as/DMS

В этом примере можно было бы передать представление десятичных градусов (в виде JSON или другого формата) в теле запроса и получить представление градусов-минут-секунд в теле ответа.

Это, конечно, работает, но кажется неустойчивым, в частности потому, что один и тот же URI используется снова и снова для разных входных данных (разные десятичные степени). Хитрость, вероятно, заключается в том, чтобы действительно сосредоточиться на том, какой ресурс им манипулирует. Возможно, это «Конверсия»:

POST /coordinate/conversions

Тело может принимать значение a, его формат и желаемый результат. Однако URI по-прежнему одинаков для всех ресурсов...

Мысли?


person SingleShot    schedule 17.08.2011    source источник


Ответы (1)


Я бы предложил использовать параметры и GET. Я бы также переключил элементы пути и сделал /conversions вашим корневым ресурсом, поскольку преобразование — это ваше «ядро домена».

Основные причины:

  • С точки зрения API-клиента выше проще в использовании (без полезной нагрузки POST, очень легко протестировать/опробовать). Удобство для клиента — один из главных приоритетов API-дизайна.
  • GET подходит лучше, потому что вы ничего не «меняете» на стороне сервера, а скорее конвертируете вещи.
GET /conversions/coordinate?input=xxx&format=yyy

Мне нравится ваш подход к возврату метаданных с помощью /conversions/formats. Это упрощает поиск форматов и делает ваш API более понятным. Соответствующие данные затем формируют возможное значение параметра «формат» из вышеуказанного вызова.

Или вы сохраняете преобразование (что будет способствовать методу POST с изменением состояния)?

person manuel aldana    schedule 17.08.2011
comment
Спасибо. Нет, состояния сервера нет. Я думаю, что предпочитаю твой взгляд на это. Я подожду и посмотрю, какие идеи появятся у других, прежде чем принять. - person SingleShot; 18.08.2011
comment
как мне добиться чего-то подобного, если ввод представляет собой файл/поток, который необходимо преобразовать? - person fra; 07.02.2017
comment
@manuel-aldana, я также думаю, что GET здесь более подходящее действие, поскольку преобразование ничего не меняет на сервере. Однако бывают случаи, когда вы хотите преобразовать более крупный объект, который не подходит для помещения (большого двоичного объекта json) в параметр запроса. Затем идет долгое обсуждение swagger-ui, github.com/swagger-api/ swagger-ui/issues/2136, и окончательный вердикт: GET не поддерживает полезную нагрузку в теле. Что ты думаешь? Вы бы вместо этого использовали POST? - person chepukha; 10.03.2020