5

I have been searching the net for an answer, but I was not able to find a similair question nor answer. So here I am.

I am developing an app where a user can take a picture of a car and they will get back the car brand and possibly a model.

Currently I am using an API as a back-end to recieve the picture, the API will send the picture to a different API which can recognize the car + model. The response will be sent back to my API, I will sanitize the response and send it back to the app.

I was wondering if this would be a good structure or if I could do it like the picture below.

Current application flow: Current application flow

What I think might be better but less secure application flow:

New application flow: New application flow

My question here is, is it possible for the last application flow to be implemented so I don't have to send a picture twice, but I can just send a picture from my app directly to the API that is not mine, get the token back and get the response that way. My concern with this is that I will need to give people with an App my API_key so they can do requests to the Api that is not mine. There is the possibility of using oAuth1 but I don't know if my api key will be secure enough that way, any advice will be appreciated.

EDIT1 My sanitize function in my own back-end api is too big to implement in the App itself.

Community
  • 1
Gertjan Brouwer
  • 1,021
  • 1
  • 7
  • 10
  • 1
    What problem are you trying to solve? If the request is taking too long, returning Accepted with a location to poll for the eventual result is probably a good idea. If it's a security issue, what's the threat model? If you want the user to call the other API directly, what prevents you from cutting your backend out of that loop entirely? What's the *problem* with having your backend act as a proxy to the other API? – jonrsharpe Mar 04 '17 at 14:31
  • I think taking away the extra load time from uploading an image from my api to the other api might cause a faster response to the user, but when I let the user upload the image to the other api I feel like it might be a security issue because they will need my personal api key to that 3rd party api so what would be a method to sercurely use my api key on multiple apps. Also it is not possible for the app to do the sanitizing my back-end api is currently doing because it needs a whole lot of data which is not available to the user. @jonrsharpe – Gertjan Brouwer Mar 04 '17 at 18:12
  • Then *do not distribute your API key*, I would return 202 accepted on the initial request; at least the request won't time out and *you* control what your users get told in the meantime if the remote API is slower than expected. – jonrsharpe Mar 04 '17 at 20:36

3 Answers3

3

There are three (edit: four) reasons I would not go for this.

  1. You are reliant upon the third party API to do additional integration with your API, to return a token, and then provide a response from a token not an uploaded image. So you'd need to know they would provide that integration and maintain it

  2. You're getting your clients (the app) to make two API calls to do a single operation and that would need documenting because it isn't a standard concept, so you'd need to document and provide support for it.

  3. Dealing with authentication is hard and requires time and thought. When you can avoid it, I'd always try to.

  4. If you're giving your API key to your clients what's to stop them following your procedure and not just directly calling the image analysis method directly and short cutting you?

I agree with other commenters that option 1 is sensible. You're keeping your implementations as a black box to your clients and one day, when you find a better third party API which is faster and cheaper and does better recognition - you only need to update your API and don't need to care about that from your clients point of view.

If you're worried about transfer speeds, why not look at some image resizing on the client first, or have your client upload to something like Azure blob / Amazon S3 storage and just pass around URLs?

bgs264
  • 166
  • 5
1

Splitting the business logic in the client and back end is not a good practice imo. You should either do it fully in your back end OR the client, and in my opinion it should be done fully in your back end. So picture 1 is the way to go.

tjugg
  • 338
  • 1
  • 3
  • 6
  • So a second or two delay in the request should not matter? – Gertjan Brouwer Mar 04 '17 at 12:30
  • 1
    @GertjanBrouwer: That depends on how fast your users expect a response. But if transferring the image between the two API's over fast broadband connections takes 2 seconds, then it is likely that transferring the image from the app will take significantly more time (in the order of tens of seconds), so an additional 2 doesn't really matter. – Bart van Ingen Schenau Mar 04 '17 at 15:15
0

I agree with the general consensus...

  1. The load on your server to route these images will be minimal until you're too successful, which at that point the higher load does not matter.
  2. The alternative has a lot more dev time involved.
  3. The alternative is not secure.
    1. If the other service changes how they operate, it's much faster fixed at backend.
    2. The client will be much easier to build and maintain, as it will be less error prone.

An alternative could be to have the client upload to S3 then just send the address to your backend for processing. S3 has security systems, or you could keep it simple and just setup your bucket to delete all messages that are an hr old...

Andres Canella
  • 101
  • 2