Cancel requests from client?

[anonymous]

I’m a frontend developer (iOS), been using an (external) API (that uses apigee) for about a year. Today, we received a warning from the owners that we need to stop cancelling our requests.

The query in question is a text search, where we (on frontend) use a debouncer to throttle our queries to prevent performing a query for each character written. The timer is set to 0.2 seconds.

Let’s say the user writes “Washingto”, and then uses 0.250 seconds to type the last “n”. In this case we perform the search for “Washingto” after 0.200 seconds, and then when they 0.050 seconds later type the letter “n”, then we immediately cancel the first outgoing query, and wait another 0.200 seconds to perform the query for “Washington” (unless they write more). etc.

And we cancel by using standard local api’s, like iOS URLSessionTask.cancel.

We cancel because the respons for “Washingto” is utterly useless for us, as we already know that the user actually want to search for “Washington”. By cancelling, we don’t have to wait for a response, saving us both data usage(mobile), processor(parsing data), and thus battery usage.

The external api-team gets thousands of status code 499 in their logs every hour because of this, and they say that “apigee claims that it’s bad practice for clients to cancel connections. That may be discussed, and we see your reasoning for doing so, but apigee are leading on the subject, so this shouldn’t be ‘standard practice’”.

They want us to stop cancelling the requests, and just receive the response.

My gut (and my research) tells me we have used the best practice by cancelling our useless outgoing requests. Is it really discouraged to cancel requests from clients when using apigee?

[dchiesa1]

i’m with you.

The 499 may be annoying, but it’s fair and valid for a client to simply cancel a request, drop the connection. In fact it’s respectful to the server; it’s a way the client can tell the server “forget that request” and if the server is built to handle that notification, then it will save server resources.

Where did this claim come from?

“Apigee claims that it’s bad practice for clients to cancel connections.”

I am not aware of such clear and specific guidance. Can you cite a source? Maybe I missed it.

Apigee typically provides more general guidance. For example, Apigee generally recommends an “outside in” approach to designing APIs; in other words “design for the consumer of the API”.

The design of an API, as with the design of any complex system, is always a compromise. There are multiple conflicting constraints. Do it fast and cheap. Make it easy and make it secure. And so on.

In my way of thinking, a well-designed, evolved API is built through a kind of informal negotiation, between the API provide and the API consumer (a developer, or a set of developers, or multiple sets of developers with different preferences). I described the process as an “informal negotiation” because often the consumer of the API is not invited to sit at the conference room table and discuss the pros and cons of the various design choices. There is no formal representation of the consumer. The idea behind “outside in” thinking is, when resolving those design constraints during this negotiation, keep in mind the end consumer of what you’re producing.

In your case, the Apigee philosophy recommends that the API should be designed to accommodate YOU. And if you, as you build a responsive, efficient iOS app, find it convenient and appropriate to cancel API requests, the API server should be prepared to handle that behavior gracefully.

If the API Provider team don"t like the 499’s in the log files, they can just filter them out.