0

I have a RESTful interface and mainly one function. The function mainly takes one big binary file as input and returns the modified file. Let's assume it's an encryption function (it's not, but similar). Nothing gets stored on the server, so repeating the call is no problem. I also need to pass many parameters, like type of encryption, some information about the caller, if the file needs to be converted first, etc.

I was thinking to implement this with a URL with something like this: //server/v1/encrypt, a POST request, and all parameters including the file (base64 encoded) in a JSON in the body.

Now the JSON definition says POST should be used for creation requests and it cannot be cached. Caching is not really important for me (as the file is always different), but I would like to follow standards and recommendations and best practice.

I would assume for the type of request, the best would be to use GET, but GET cannot have a file in the body (as per question 978061). And also the parameters in the body as JSON is probably also not a good idea. But is it really better to have 50 parameters in the URL (either as part of the path or part of GET parameters)?

How would you implement this and why?

e4ch
  • 31
  • 1
  • 5
  • how do you imagine a rest interface without any resources? Me, I'd either not bother at all (just POST data to some action), or rename an action to something like `POST /api/encryption_requests`. This way, your encryption task is a "request" and you "create" it. – Sergio Tulentsev Aug 29 '17 at 10:00
  • @SergioTulentsev Are you saying that the functionality I need is not covered by the REST standard, because I'm not accessing _resources_ directly and instead fulfilling some _requests_ only? I think all the usual web backend APIs have this (or a similar) problem somewhere. You're also saying that you would do it as I initially planned - that already helps a bit, thanks. – e4ch Aug 29 '17 at 15:08

0 Answers0