Правильно ли это REST api?

Я работаю над системой развертывания, для которой требуется некоторое приложение, развернутое в пуле на всех или подмножестве машин в пуле. Чтобы это было просто, скажем, у меня есть только 3 требования к api.Правильно ли это REST api?

развернуть
отменить
статус

теперь я запутался о проектировании Вызовы API REST для вышеуказанных действий: Вот что я имею в виду. Если полезная нагрузка пуста, я развертываю на всех машинах в пуле.

http://my-endpoint/api/{pool-name}/deploy 

Payload: 
{ 
    "machines" : [ 
     "machine-1.fqdn", 
     "machine-2.fqdn", 
     "machine-3.fqdn" 
    ] 
} 
Response: 
{ 
    "status": "OK", 
    "jobId": "9999" 
}

Клиент может затем опрашивает статус или отменить развертывание на основе JobId:

http://my-endpoint/api/{pool-name}/status/{jobId} 
http://my-endpoint/api/{pool-name}/cancel/{jobId}

Теперь JobId уникален во всей системе развертывания так что наличие {пул имен} в api для «статуса» и «отмены» не кажется правильным. Это хороший дизайн? Я прочитал ряд статей в Интернете, в которых рассказывается о картографических действиях в REST, и они только помогли добавить к моей путанице. У меня нет CRUD как такового в моем приложении. Я просто хочу убедиться, что я делаю это правильно. Может кто-нибудь указать на недостатки в дизайне? Любые указатели помогут.

источник

2013-10-06 Vaibhav Desai

Выглядит хорошо для меня! –

Я бы удалил часть «/ api» в URL-адресе, но остальное выглядит отлично. – Farid

Благодарим вас за комментарии. –

Пара мыслей:

Во-первых, ваши ответы не допускает возможности, что некоторые машины работают и некоторые машины не делают. Таким образом, ваш ответ, вероятно, должен быть массивом со статусом на каждую попытку.

Во-вторых, это не является абсолютно спокойным, вы создаете URL-адреса, которые являются эффективными глаголами. Прагматично это будет работать, но чтобы быть RESTful, вы должны идентифицировать свои сущности и использовать GET, PUT, POST и DELETE.

Таким образом, ваша сущность может быть просто Job.

PUT to /myendpoint/api/job

с полезной нагрузкой, содержащей имя пула и массив машин. ответ будет представлять собой массив статусов и идентификаторов работы.

[ 
{ 
"status": "OK", 
"jobId": "m1-9999" 
},{ 
"status": "OK", 
"jobId": "m2-9999" 
},{ 
"status": "BAD", 
"machine": "m3" 
"reason": "xxx" 
} 
]

У вас есть идентификатор задания, чтобы получить статус. Рабочее место достаточно, чтобы определить, на какой машине он включен.

GET myendpoint/api/job/m2-9999

и POST на тот же URL с полезной нагрузкой «отменить», чтобы отменить работу.

источник

2013-10-06 07:20:04 djna

+1, за исключением того, что семантика PUT здесь не уместна - PUT должен создать новый ресурс по URL-адресу, на который задан. Используйте POST. –

@djna большое спасибо. Ты посадил меня на правильный путь. Что касается вашего наблюдения за статусом на машину, я согласен. Я должен был упомянуть, что развертывание просто создает новое задание, которое выбирается Quartz. Все сведения о выполнении задания возвращаются клиенту в вызове состояния. –

@AntonTykhyy Да, я буду использовать POST. Я считаю, что мне не нужно выставлять PUT, так как ничего не изменится после создания задания. Это может быть отменено или запрошено только для статуса. –

Для отмены и состояния, я бы на самом деле предпочитают следующие

http://my-endpoint/api/{pool-name}/cancel/{job-id}

Мой дизайн будет не предпринимать никаких действий для пустой полезной нагрузки запроса. Это делается для того, чтобы несерьезные пользователи атакуют API без необходимости. Я ожидал бы полезную нагрузку, а затем возвращаю обратно ответ «Ошибка».

Снова для успешной Отмена/Статус, будет отправить обратно ответ, как

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<request-result> 
<http-code>200</http-code> 
<description>REST Request is successfully processed</description> 
<internal-error-info></internal-error-info> 
<message>Job with {id} is processed successfully</message> 
<requested-operation>Cancel</requested-operation> 
<resource-name>JobName</resource-name> 
<status>SUCCESSFUL</status> 
</request-result>

источник

2014-06-04 00:43:45 Rockoder

Правильно ли это REST api?

ответ

Смежные вопросы