Это в порядке REST для возврата содержания после POST?
read делает это:
user@host:~$ read -n1 -r -p "Press any key to continue..." key
[...]
user@host:~$
Эти -n1 определяет, что это только ожидает отдельного символа. Эти -r помещает его в режим без предварительной обработки, который необходим, потому что иначе при нажатии чего-то как обратная косая черта это не регистрируется, пока Вы не нажимаете следующую клавишу. Эти -p определяет подсказку, которая должна быть заключена в кавычки, если она содержит пробелы. key аргумент только необходим, если Вы хотите знать, какую клавишу они нажали, в этом случае можно получить доступ к нему до $key.
при использовании Bash можно также определить тайм-аут с -t, который заставляет чтение возвращать отказ, когда клавиша не нажата. Так, например:
read -t5 -n1 -r -p 'Press any key in the next five seconds...' key
if [ "$?" -eq "0" ]; then
echo 'A key was pressed.'
else
echo 'No key was pressed.'
fi
5 ответов
REST just says that you should conform to the uniform interface. In other words, it says you should do what POST is supposed to do as per the HTTP spec. Here is the quote from that spec that is relevant,
If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).
As you can see from this, you have two places where you can indicate to the client where the newly created resource resides. The Location header should have an URL that points to the new resource and you can return an entity with the details also.
I'm not sure what the difference between overriding acceptRepresentation() and overriding post() but this example shows how to return a response from a POST.
Output it in whatever format is requested. That might be:
<success>
<id>5483</id>
</success>
Or:
{ "type": "success", "id": 5483 }
It depends on what you usually do. If they're not expecting the data, they should just ignore it, but any client that wants to handle it properly should be able to.
Два разных вопроса:
Поддерживает ли шаблон приложения REST возврат данных в POST?
Я не думаю, что REST явно запрещает это, но предпочтительный способ обработки описан в Ответ Даррела.
Позволяет ли структура RESTlet возвращать данные в POST?
Да, даже если он возвращает void, в классе, расширяющем ресурс, у вас есть полный доступ к объекту объекта Response через метод getResponse () . Таким образом, вы можете вызывать getResponse (). SetEntity () с любыми данными.
Если вы отвечаете 201 Created с телом объекта, а не с перенаправлением Location, то рекомендуется включить заголовок Content-Location, указывающий на ресурс, который представлен в ответе.
Это позволит избежать потенциальной путаницы, когда клиент может (оправданно) предположить, что объект ответа на самом деле представляет новое состояние «создателя», а не созданный ресурс.
> POST /collection
> ..new item..
< 201 Created
< Location: /collection/1354
< Content-Location: /collection/1354
< <div class="item">This is the new item that was created</div>
Я бы отказался от отправки чего-либо в теле ответа. Просто установите Location: на (полный) URL-адрес вновь созданного ресурса.
Ваше описание предполагает, что это именно та семантика, которую вы:
- POST-сообщение для его создания
- Ответьте достаточно, чтобы знать две вещи:
- Произошло создание (201)
- Где найти новую вещь (заголовок Location)
Все остальное излишне.