CODEWITHSUNDEEP
parsingrestdesign-patterns
W.K.S
W.K.S

Reputation: 10095

REST call may results in two different JSON objects. What design pattern should I use?

My web application makes a REST call. If the call is successful, it will return a 'weather' json object. If the call fails, it will return a json error object.

I want to make a class that parses the resulting JSON and returns a Weather object if the call succeeded and an Error Object if the call failed.

I'm thinking of using the Factory pattern but I'm not sure if that's a good approach because the two objects are very different from one another. What is a good way to design this code?

Upvotes: 0

Views: 215

Answers (4)

Pete
Pete

Reputation: 11495

Does the Content-Type header vary depending on the type of response?

As some have noted in their answers, the HTTP status code should be used to determine "Was there an error", but just as important is the interpretation of the content type returned.

Hoping the Content-Type header does vary, I would suggest using a registry of parsers, registered by content-type they handle, and then delegate to them to handle understanding how to convert a particular content type into the object you want. In Ruby, since you didn't specify a particular language:

case response.status:
  when 200..299
    return parsers[response.content_type].parse(response.body)
  when 400..499
    raise parsers[response.content_type].parse(response.body)
  else
    raise "Unhandled response status"

Doing so separates the two concerns:

  • Determining if there was an error
  • Parsing of content types into classes/types in your application.

Upvotes: 0

rae1
rae1

Reputation: 6144

You need first to check the result of the call, and then make a decision on how to handle it, with the possibility of handling all error codes with an error callback that returns an Error JSON object, and a success callback to return a Weather JSON object. You can use the HTTP codes to create a proper response and further subdivide the logic to return more specific errors, if needed.

The use of a Factory pattern seems overkill, specially given that the objects don't relate to each other.

Upvotes: 1

moonwave99
moonwave99

Reputation: 22817

It really depends on the environment you'll be using your API.

As a rule of thumb, rely on the HTTP code - if you get a 404 or a 500 of course you can't come up with a parsed response.

Format your error responses in a consistent way, e.g.

404 { "message" : "Resource not found" }
400 { "message" : "Wrong parameters given" }

So you know how to parse them.

If you get a 200 OKyou know everything was right, and you can parse your response with no problem at all.

Upvotes: 0

Michael Banzon
Michael Banzon

Reputation: 4967

A common approach I use is to have Weather and Error both be Response objects and have a ResponseFactory create them.

I strongly encourage you to use proper HTTP codes when designing your service as they give a more general view of the state and success of each call.

Upvotes: 1

Related Questions