RESTfull дизайн интерфейса, PUT или POST при утверждении ресурса приложения - PullRequest
Новая
       9

RESTfull дизайн интерфейса, PUT или POST при утверждении ресурса приложения

1 голос
/ 15 декабря 2011

Я разрабатываю систему RESTfull, которая используется веб-сайтом для отправки форм заявок, а затем используется внутренним инструментом для авторизации или отклонения этих приложений. У меня в голове спор о том, как это построить, и у меня есть два варианта. PUT или POST.

опция PUT

Все приложения перечислены в списке и ресурс приложения, который можно отфильтровать по коду состояния (новый, утвержденный, отклоненный) с помощью параметра запроса (состояния, предоставляемые через другой ресурс). Новые заявки могут быть размещены на этот URL, который создает их и назначает и ID. Затем вы можете получить доступ к приложению с помощью GET, используя его идентификатор. Для подтверждения вы помещаете один из кодов состояния в URL-адрес приложения, чтобы обновить запись. 

     GET Service.svc/statecodes
GET POST Service.svc/Applications?statecode={statecode} /{POST DATA}
 GET PUT Service.svc/Applications/{applicationId} statecode={statecode}

ОПЦИЯ ПОЧТЫ

Все приложения перечислены в разделе «Ресурсы приложений», на этот URL можно публиковать новые приложения, которые их создают, присваивают и идентифицируют. Существуют различные URL-адреса, которые показывают отфильтрованные представления приложений: ожидающие решения, утвержденные, отклоненные. Для подтверждения applicationId будет размещен на утвержденном URL, а для отклонения URL будет опубликован отклоненный URL. Эти последние два сообщения будут иметь эффект или переместить приложение из списка ожидания в список утвержденных. 

    POST Service.svc/Applications form={POST DATA}
     GET Service.svc/Applications/{applicationId}
     GET Service.svc/Applications/pending
GET POST Service.svc/Applications/approved applicationId={applicationId}
GET POST Service.svc/Applications/declined applicationId={applicationId}

Мне кажется, что метод PUT наиболее полезен, но подвергает поведение внешнему миру и нарушает инкапсуляцию. Метод POST выглядит чище и более обнаружим, но мне не нравятся побочные эффекты POST для ресурса на другом ресурсе.

Я чувствую, что на самом деле мы должны использовать SOAP для утверждения и отклонения, так как это команда / сообщение, а не запрос, который на самом деле и есть REST, но я застрял на пути сверху, если кто-то может помочь мне сформировать аргумент для SOAP.

Так какой же подход правильный или лучший?

1 Ответ

1 голос
/ 15 декабря 2011

Получить / установить приложение state: 

GET PUT /application/{id}/state

Если это не публичный интерфейс, вы можете просто вернуть 403 (или 401, если возможно получить разрешение на получение / установку состояния), если запрос не от внутреннего инструмента.

Подайте новое заявление и просмотрите его: 

POST /application/
GET  /application/{id}

Вы также можете открыть все приложения с определенным состоянием: 

GET /application?state={pending|approved|declined}

Один и тот же ресурс может иметь несколько URL, если вы хотите, например, набор приложений, находящихся в состоянии pending: 

/state/pending/application

и 

/application?state=pending

помогите мне сформировать аргумент для SOAP.

Пример того, как может проходить обсуждение, см. Должен ли веб-сервис в стиле Netflix или Twitter использовать REST или SOAP? .

...