Необходимые мнения об атомарности ПОМЕЩЕННОГО УСПОКОИТЕЛЬНОГО
Ничто не гарантируется, если процесс будет уничтожен преждевременно, однако, я использую" using", чтобы сделать это..
using System;
using System.IO;
sealed class TempFile : IDisposable
{
string path;
public TempFile() : this(System.IO.Path.GetTempFileName()) { }
public TempFile(string path)
{
if (string.IsNullOrEmpty(path)) throw new ArgumentNullException("path");
this.path = path;
}
public string Path
{
get
{
if (path == null) throw new ObjectDisposedException(GetType().Name);
return path;
}
}
~TempFile() { Dispose(false); }
public void Dispose() { Dispose(true); }
private void Dispose(bool disposing)
{
if (disposing)
{
GC.SuppressFinalize(this);
}
if (path != null)
{
try { File.Delete(path); }
catch { } // best effort
path = null;
}
}
}
static class Program
{
static void Main()
{
string path;
using (var tmp = new TempFile())
{
path = tmp.Path;
Console.WriteLine(File.Exists(path));
}
Console.WriteLine(File.Exists(path));
}
}
Теперь, когда эти TempFile расположен или собрал "мусор", файл удален (если возможный). Вы могли, очевидно, использовать это, как плотно ограниченный по объему как Вам угодно или в наборе где-нибудь.
5 ответов
+1 за философию REST.
Без подробных знаний спецификации HTTP я бы просто выбрал один из вариантов и задокументировал затруднительное положение и выбор.
Я бы предпочел Если сервер не может ответить по запросу, то он не должен обрабатывать запросы вообще.
Но это может не работать в некоторых сценариях, поэтому вам, возможно, придется сделать наоборот.
UPDATE table SET field = 1 - field
Примечание: серверам HTTP / 1.1 разрешено возвращать ответы, которые являются
неприемлемо в соответствии с заголовками accept, отправленными в
запрос. В некоторых случаях это может быть даже предпочтительнее отправки
406 ответ. Пользовательским агентам рекомендуется проверять заголовки
входящий ответ, чтобы определить, приемлемо ли это.
Если ответ может быть неприемлемым, пользовательскому агенту СЛЕДУЕТ временно прекратить прием дополнительных данных и запросить у пользователя решение о дальнейших действиях.
Это примечание в середине о HTTP / 1.1 может быть вашим ответом. Я прочитал это как высказывание «вы можете вернуть 200 в ответ на запрос PUT к / People / Bob, когда пользовательский агент указывает application / xml в заголовке Accept, выбирая любой подходящий тип контента, и этот результат может быть предпочтительнее, чем возвращает 406. "
В этом сценарии PUT будет успешным на сервере, вернет 200, но клиент получит представление application / json. Клиент должен иметь возможность справиться с этой возможностью, убедившись, что он понимает тип носителя, указанный в заголовке Content-type, и ведет себя четко определенным образом, если это не так.
Но это всегда верно в любом случае. .
Еще одна вещь: вы можете решить не использовать обычные типы мультимедиа, такие как application / xml и application / json, а вместо этого определить свои собственные типы мультимедиа, возможно, на основе XHTML или JSON. Все взаимодействие клиент-сервер в приложении RESTful происходит через типы носителей. Без типов мультимедиа, достаточно богатых, чтобы охватить концепции вашей предметной области, вы не полностью указываете свой REST API.
Я бы сказал «да» теоретически, но «нет» для реальных приложений.
Я вижу логику в том, чтобы не обрабатывать данные в случае ошибки. Поскольку вы возвращаете 406, а не 500, я бы знал, что это не ошибка в предоставленных мной данных, а скорее в том, как результат представляется мне.
Тем не менее, некоторые приложения не будут проверять коды ошибок; они просто увидят, что он вернулся с ошибкой, а не с запрошенным XML, и предположат, что транзакция не удалась.
Я полагаю, что ваша необработка application / xml не является реальной проблемой, но для целей вопроса - если это на самом деле развертывается как реальная служба, вы почти наверняка захотите иметь представление XML, поскольку это (я подозреваю) наиболее распространенное взаимодействие RESTful, и многие вызывающие, вероятно, будут жестко запрограммированы на используйте XML.
Подводя итог: если вы на самом деле не предоставляете application / xml, я бы сказал, не выполняйте обновление. Если вы соблюдаете все стандарты, но вы
Один из выходов из вашей головоломки - это успешная PUT , возвращающая 204 (без содержимого). Таким образом, заголовок клиента Accept не имеет отношения к вопросу о том, выполняется ли обновление.
«RESTful» (или, по крайней мере, «HTTP-охватывающий») клиент будет знать, что не обновлять свой текущий » page ", и что ему нужно будет выполнить GET , чтобы обновить свое представление о ресурсе just- PUT . Заголовок Accept в этом GET теперь, конечно, является отдельной проблемой, нежели атомарность обновления.
I would either succeed and return a 200 using the method Rich suggests above or a 406 and fail. The protocol does not allow for a more nuanced approach mixing 2xx (Success) with 4xx (Error) codes so 4xx can be read to imply NOT Success.