Exception handling between API's and between API and Frontend

[Solverj]

How do you guys handle decisions based on ProblemDetails between the API layer and Frontend?

status, type, detail, instance

I.e.,

1. ChildService calls MotherService -> "Can I have IceCream?"
2. MotherService responds -> 403, https://mother.com/frown-face-annoyed-saying-no, "mother is stressed, ask later", 32939219
3. ChildService responds to ChildFrontend -> 403, https://child.com/angry-lay-down-scream, "child should be carried out of store", 239219

From 2 -> 3 it's clear we've done a transformation of the problem and the frontend might act differently on it, I hope my analogy was clear (I had some fun with it)

[whiskeysierra]

I understand the scenario that you're describing but I don't fully grasp the problem (pun intended) yet.

[Solverj]

Which field of: status, type, detail, instance should the frontend act upon? i.e., like exceptionhandling. In RFC 7807 I didn't really get which field we should machinewise act upon. It might be that sometimes the childFrontend above might lay down screaming, but might also say "OK, and is happy with that". How do we do this?

The issue I have with "type" field is that it might have different hosts depending on environment. So many questions and I'm hoping that you guys have it all figured out! :)

[whiskeysierra]

Which field of: status, type, detail, instance should the frontend act upon? i.e., like exceptionhandling. In RFC 7807 I didn't really get which field we should machinewise act upon.

See https://tools.ietf.org/html/rfc7807#page-5. title and detail are human-readable. The rest is for machines.

It might be that sometimes the childFrontend above might lay down screaming, but might also say "OK, and is happy with that". How do we do this?

Up to you, how you design your problem types.

The issue I have with "type" field is that it might have different hosts depending on environment.

No, that's the wrong use. Treat type primarily as an opaque string, it might not be resolvable to a web page anyway.

[Solverj]

What about this? I read this as "type" is what MUST be used in-order to fulfill the RFC7807 specification.

I appreciate the time you take to respond to these questions.

[whiskeysierra]

That quote doesn't really contradict what I'm saying, does it? Think of type as the class of problem. E.g. you might have a out-of-stock problem type (from the README):

{
  "type": "https://example.org/out-of-stock",
  "title": "Out of Stock",
  "status": 400,
  "detail": "Item B00027Y5QG is no longer available",
  "product": "B00027Y5QG"
}

The type is always the same for the same kind/class/type of problems. The title is just a human-readable version of the type. In contrast to type and title, which are constant for the same kind of problems, there are instance (omitted in the example above) and detail. instance is the machine readable identifier of a particular instance of a problem, i.e. it would change for every occurrence. detail is the human-readable version of instance.

[Solverj]

It does not contradict what you're saying, I'm merely trying to fill in the blanks of my understanding and I might come across to many as imperative (as you might have felt here) I'm trying to use emotes to signal my emotional response. Thanks for your time, I think this is enough.

[whiskeysierra]

This is how visualize it in my head:

	Class	Instance
Machine-readable	type	instance
Human-readable	title	detail