>Just because it's the same app preparing both the transport and the application, you think that it's the same layer of comms?

Yes, that's what I think.

I don't see any other way of dividing it, which is why I asked what you think the boundary is otherwise.

Again: Can you explain what you think the boundary is between the application layer and transport layer in a Go web app?

>The "not found" is not an application level error, even if, in your backend, you mixed them all up into the same function.

If the request is something like /user/detail/12345 and user 12345 doesn't exist, what should the response be?

▲

lelanthran 2 days ago | parent [-]

>> Just because it's the same app preparing both the transport and the application, you think that it's the same layer of comms?

> Yes, that's what I think.

If you don't know how communications composed of multiple layers work, I'm afraid I can't really help with that understanding in a comment section on a forum.

I mean, for example, you can use git over ssh or git over https, but no one thinks that the git communications + https (or git comms + ssh) is a single layer.

> Again: Can you explain what you think the boundary is between the application layer and transport layer in a Go web app?

A single Go web app also does SMTP and TCP[1]. Do you also think that SMTP and TCP are on the same comms layer(s) as HTTP and REST?

Many Go apps also support SSL. Does that mean it is okay for the HTTP webserver to put HTTP-specific content into the SSL layer?

---------------------

[1] Maybe you have a Go webapp that never needs to send confirmation emails, but when I last did that in Go, the Go app needed to reach into the TCP stack (specifically to set socket options) in order to make SMTP work.

	▲	aatd86 a day ago \| parent \| next [-]
		I am interested in any answer to this > If the request is something like /user/detail/12345 and user 12345 doesn't exist, what should the response be? This is quite an interesting question. If we consider that webservers host paginated applications, the answer would be that this is indeed an application level concern and we should return a 404 since the resource is not found. SPAs without SSR may have muddled this since the application is about serving a client side application then. We could expect a 200. It is not as straightforward as it seems perhaps...
	▲	mtlynch a day ago \| parent \| prev [-]
		>If you don't know how communications composed of multiple layers work, I'm afraid I can't really help with that understanding in a comment section on a forum. I'm not asking you to explain protocol stacks, and I feel like that's obvious. I've been open to your viewpoint, and I've asked you to clarify your position. Instead you just keep mocking me and feigning surprise that I hold a pretty mainstream view. At this point, I'm left to assume you're either trolling or you have a viewpoint that can't bear scrutiny, so I'll stop engaging with you.