REST URL для преобразования одного ресурса в другой ресурс - PullRequest
Новая
       70

REST URL для преобразования одного ресурса в другой ресурс

0 голосов
/ 06 ноября 2019

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

У меня есть 2 ресурса Workunit и Document. У меня есть 3 операции над этими двумя ресурсами

1> trasform Workunit в Document
2> sync Workunit в Document (логика, отличная от преобразования)
3> transform Document в Workunit

и у меня есть следующие URL 

[POST]  api/v1/workunits/transform
[POST]  api/v1/workunits/sync
[POST]  api/v1/documents/transform

проблема здесь в том, что действие является частью REST URL

какие-либо предложения?

Ответы [ 2 ]

0 голосов
/ 06 ноября 2019

С данной ситуацией все в порядке.

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

Вам решать, но подумайте об изменениинемного структурировать:

Разделить логику Transformation и Sync на два разных контроллера, чтобы вы могли избежать проблем с URL.

  • TransformationController

    [Route("api/v1/transformation-controller/")]
TransformationController : ControllerBase
{
     [HttpPost("workunits")]
     public Task<Response> TransformWorkunits()
     {
          //logic
     }

     [HttpPost("documents")]
     public Task<Response> TransformDocuments()
     {
          //logic
     }
}

  • SynchronizationController

    [Route("api/v1/synchronization-controller/")]
TransformationController : ControllerBase
{
     [HttpPost("workunits")]
     public Task<Response> SyncWorkunits()
     {
          //logic
     }
}

Таким образом, URL будут:

  • [POST] api/v1/transformation-controller/workunits
  • [POST] api/v1/synchronization-controller/workunits
  • [POST] api/v1/transformation-controller/documents

Так что это способ избежать глаголов и соответствовать правилам REST.

Если будетЧем больше объектов вы хотите преобразовать / синхронизировать, то вам придется улучшить этот подход.

0 голосов
/ 06 ноября 2019

проблема здесь в том, что действие является частью REST URL

Это не проблема - клиенты не зависят от URL для семантики, поэтому вы можете использовать любое написание, которое вам нравится;api/v1/4dc233fa-c77c-49d7-b7d6-296ffeb89612 вполне удовлетворительно.

Это аналогично наличию глагола в качестве имени переменной - это может не соответствовать вашим локальным стандартам кодирования, но компилятору все равно. То же самое относится и к вашему URL, и к компонентам общего назначения, которые его используют.

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

Таким образом, обычным шаблоном может быть POST-сообщение transform в ресурс workunit или POSTtransform сообщение для ресурса Document или POST для синхронизации сообщения с ресурсом Workunit.

Хм, последнее звучит задом наперед;если рабочий блок не изменился, а документ был изменен синхронизацией, то вы, вероятно, отправили бы сообщение синхронизации на ресурс документа.

Так что, если у меня есть / api / v1 / documents / 1, и мне нужночтобы синхронизировать его, я обычно использовал бы POST /api/v1/documents/1 с семантикой синхронизации, описанной в теле сообщения (в Интернете это обычно было бы application/x-www-form-urlencoded представление сообщения синхронизации).

Но этос таким же успехом может быть сообщение «Синхронизировать документы / 1 с workitem / 2», что я POST в списке задач синхронизатора.

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

...