Use common req_perform_ prefix

[hadley]

Fixes #314

[mgirlich]

Maybe this should be req_perform_parallel()? At least this sounds a bit more intuitive to me.

[hadley]

Oh yeah, I like that name.

[mgirlich]

I'm not sure we want to stick with req_perform_paginate() in the end. If we add req_chunk() we would either have to add req_perform_chunk() or change req_chunk() to return a list of requests.
Or we change the name to something like req_perform_iterative() which would cover paginated and chunked requests.

[hadley]

How about req_perform_iterate()?

[hadley]

@mgirlich should we rename req_stream() to req_perform_stream()?

[mgirlich]

I like req_perform_stream() and req_perform_iterate()!

[hadley]

I really like this section now. Feels like the functions fit together into a whole.

[hadley]

This makes me lean towards making the next release 1.0.0 again.

[hadley]

I'm swinging towards req_perform_iteratively() since that would match req_perform_parallel() better — i.e. perform iteratively; perform in parallel.

Or possibly req_perform_sequential()? But that does lose the "next request is generated from current response" implication of iterative.

Maybe we need req_perform_sequential() as well though? i.e. if you have a list of requests and want to do them one at a time? (Although I'm not sure why you would want that.)

[mgirlich]

req_perform_iteratively() also sounds good and I prefer it over req_perform_sequential().

One use case that comes to my mind for req_perform_sequential() would be for requests that create something. E.g. consider GitHub: the first request creates a repository, the second request creates an issue in this repository, the third request creates a comment in this issue.

Harder to come up with something for GET requests. Basically the only things that comes to my mind is if you don't want to do too many requests (e.g. because they cost something) but you don't know whether you will need all of them.
But the most realistic case for something like this would probably be a paginated search endpoint, where you don't (really) know all the requests in advance.
This brings me to the idea that for this we might want to include a break callback to req_perform_iteratively() at some point.

[hadley]

I'll make the change to req_perform_iteratively() and then merge this PR. Let's continue to talk about the interface for iterative requests; I think if we can get this right, I'll feel happy making the next release 1.0.0 and it's worth taking some extra time to do that.