Add status Methods Which Use String or URI

[isomarcte]

These are similar to the expect methods which take the same arguments. They are particularly useful for test.

[isomarcte]

I don't think the travis failure is related to my change.

[rossabaker]

Thanks. I agree on the CI and restarted Travis.

Whether we want to do this, or move in the opposite direction, is #2483. We should agree on our strategy there, and then either approve or close this.

[ChristopherDavenport]

I'm for adding them for consistency now, but us all keeping in mind they may be removed with the other overrides sometime in the future.

[rossabaker]

If we do these, then also expectOption, expectOptionOr, etc., right? I guess I'm arguing for "all-or-none" rather than "more".

[rossabaker]

It's a lot easier to add methods than take them away, and we have a general aversion to overloads. I think this is a symptom of friction in creating requests. I'd like to think about how we can do better there.

I vote we think about this during 0.20, since 0.21 is likely just around the corner.

[isomarcte]

@rossabaker any status updates on this?

[rossabaker]

I hoped someone would come up with a simpler way of building requests that reduces the desire for overloads, but we haven't seen one yet. I'm usually opposed to overloads, but I guess I'm a mild 👍 on this, since someone cared enough to add it, and nobody has cared enough to shout it down.

[isomarcte]

@rossabaker would you prefer statusFromString and statusFromUri? I'm also not a fan of overloads. The only reason I went with that is because that was the idiom I saw in use already.

[rossabaker]

Yes, I'd be a lot more in favor of that. I'd also make clear that they're GET requests in the scaladoc.

[isomarcte]

@rossabaker will do.

[isomarcte]

@rossabaker updated.

[isomarcte]

@rossabaker oops, forgot to push. Updated now.

[ChristopherDavenport]

Reapproving to bump visibility