3 ms·

There is however one use case for which I haven't found a good way to use REST: have the client upload a document to the server and return the same document in

There is however one use case for which I haven't found a good way to use REST: have the client upload a document to the server and return the same document in a single call, transformed (say, applying an XSL server-side). You're not really creating a new resource here, or accessing an existing one. But I agree that in most cases, REST is good enough, and certainly a hell of a lot better than old-style RPC or "let's-put-an-action-verb-in-the-URL-and-call-it-REST" HTTP APIs.

icebraining 13y ago
What happens if the connection is lost during the conversion? Do you really want to force the client to send it again and redo the conversion? Is the document time sensitive enough that it's better to repeat the process? If not, then I'd say that it does make sense to create a new resource: the document. You create it by POSTing the original, and the server returns a 201 Created, with a Location header pointing to its new URL. The client can then GET it to download the converted version. The document resource should have a TTL so that it can be pruned from cache. I don't think REST fits all use cases, and RPC does make sense when your needs don't fit the advantages of following REST, but I don't think that's the case here.
- mercurial 13y ago
  > What happens if the connection is lost during the conversion? Do you really want to force the client to send it again and redo the conversion? Is the document time sensitive enough that it's better to repeat the process? No, I don't think it would be an issue to repeat the process in this case. > f not, then I'd say that it does make sense to create a new resource: the document. You create it by POSTing the original, and the server returns a 201 Created, with a Location header pointing to its new URL. The client can then GET it to download the converted version. The document resource should have a TTL so that it can be pruned from cache. I guess, but it forces the server to store the document somewhere (presumably in RAM). It's much easier and cheaper in RAM to answer the POST with the formatted document, and you also spare complexity client-side (only a single HTTP call and only a single location for error handling). But yes, it would be a possibility.

icebraining 13y ago

What happens if the connection is lost during the conversion? Do you really want to force the client to send it again and redo the conversion? Is the document time sensitive enough that it's better to repeat the process? If not, then I'd say that it does make sense to create a new resource: the document. You create it by POSTing the original, and the server returns a 201 Created, with a Location header pointing to its new URL. The client can then GET it to download the converted version. The document resource should have a TTL so that it can be pruned from cache. I don't think REST fits all use cases, and RPC does make sense when your needs don't fit the advantages of following REST, but I don't think that's the case here.

mercurial 13y ago
> What happens if the connection is lost during the conversion? Do you really want to force the client to send it again and redo the conversion? Is the document time sensitive enough that it's better to repeat the process? No, I don't think it would be an issue to repeat the process in this case. > f not, then I'd say that it does make sense to create a new resource: the document. You create it by POSTing the original, and the server returns a 201 Created, with a Location header pointing to its new URL. The client can then GET it to download the converted version. The document resource should have a TTL so that it can be pruned from cache. I guess, but it forces the server to store the document somewhere (presumably in RAM). It's much easier and cheaper in RAM to answer the POST with the formatted document, and you also spare complexity client-side (only a single HTTP call and only a single location for error handling). But yes, it would be a possibility.