Http.Error 2.0.0

Request Feedback
1

Could anyone please explain the rationale for removing http response details from BadStatus error value in version 2.0.0 leaving only status code? Now if I want to migrate to version 2.0.0 for my application to work I have to literally copy Http.Error and Response types from version 1.0.0 and use expectStringResponse function only in order to access bad http status message text or reponse body!

1 Like
2

Hey @mrumkovskis ,

Yea, I can definitely see why having to manually grab those messages from expectStringResponse would be frustrating…

Here’s the commit that modified the API:

It looks like it was a part of a bigger redesign to include files and byte data, instead of the normal HTTP stuff.

Were the messages provided by HTTP 1.0 package user friendly?

Instead of using expectStringResponse, maybe upgrading to 2.0 is a good opportunity to provide more helpful error messages! :smiley:

message : Int -> String
message statusCode =
  case statusCode of
    404 ->
      "Page not found."
    _ ->
      "Oops, something went wrong!"

Maybe someone else has a better answer to your question about the reason behind the change.

I just wanted to recommend an alternative way to upgrade your app, without the potential headache of dealing with string responses.

Have a great day,
Ryan

3

Thanks for the answer. Since in my application I use both status messages and the body of bad status responses coming from the server to do certain logic or to show error messages to the user, the only way to migrate to 2.0 seems to use expectStringResponse function.

1 Like
4

I think that these packages could help if you don’t want to do all the work:

I have not tested them though.

2 Likes
5

Http.Legacy module is exactly what I need. Thanks.
Only that for Http.Error it will not be legacy since I really need response with bad status message text and/or body :slight_smile:

6

Yeah this comes up quite often in the beginners Slack channel! And figuring out how to do it with expectStringResponse can be quite daunting when you’re just starting out. I wish elm/http did something similar to jzchuan/http-extras.

1 Like
7

This one is a good topic about the issue: https://medium.com/@jzxhuang/going-beyond-200-ok-a-guide-to-detailed-http-responses-in-elm-6ddd02322e

In my opinion it was not worth refactoring Http.Error since now it assumes you never want to process response details on bad http status which in practise is quite an opposite.

1 Like
8

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.