4 ms·

return pox.Templ(http.StatusOK, templates.AlertError("Name cannot be empty")), nil Oof, an HTTP 200 OK response with a body that says the request actually was

return pox.Templ(http.StatusOK, templates.AlertError("Name cannot be empty")), nil Oof, an HTTP 200 OK response with a body that says the request actually was not OK. I like htmx, but this is probably the weakest part of it. htmx is supposed to let you write semantic HTML, but it's obviously not semantic HTML/HTTP to respond HTTP 200 to incorrect user input. But I think OP is doing this because if they had responded HTTP 400 - Bad Request, htmx would have thrown away the response body by default.[0] [0] https://htmx.org/docs/#modifying_swapping_behavior_with_events https://htmx.org/docs/#modifying_swapping_behavior_with_even...

SwiftyBug 1y ago
I think this debate is as old as time. I can see value in arguments both for and against this pattern. It's just a pattern. GraphQL does the same thing. As long as the consumers of that endpoint is aware of that behaviour I see no harm. In most cases, these endpoints serve only the frontend of the app. I would avoid doing something like that for a public API though.
- deleted 1y ago
  [deleted]
naasking 1y ago
> htmx is supposed to let you write semantic HTML, but it's obviously not semantic HTML/HTTP to respond HTTP 200 to incorrect user input. It's perfectly semantic HTML, it just doesn't have to be semantic HTTP (as in, you don't have to push semantics to the HTTP level, keep it at the HTML level). Thinking that HTTP status codes should be semantically meaningful means you're still thinking of htmx endpoints are or must be API endpoints. That's a mistake.
- tacitusarc 1y ago
  You are, however, communicating over HTTP. If the protocol conventions cannot be used due to limitations of the encoding, it is reasonable to question the encoding design. Another comment asserted HTMX can handle this, it just needs to be configured to do so. If that is the case, then I don’t see an actual issue.
  - mtlynch 1y ago
    >Another comment asserted HTMX can handle this, it just needs to be configured to do so. If that is the case, then I don’t see an actual issue. You can, but it feels like you're sort of fighting the htmx library at that point. I do it, as it's the least bad option, but I generally find footguns with violating HTTP conventions (e.g., returning HTTP 200 for a bad request) or going outside the mainstream of a library (telling htmx that HTTP 400 can have a meaningful response body).
masfoobar 1y ago
I have not used the templ library so I cannot comment on this. However, as this is more an htmx query I will focus on this -- htmx supports returning other responses, and you can handle their behaviour if you choose to. At a basic level, validation/checks should be done on the server side. If there is a problem, you can return HTML. I dont see what the big deal is. On another note, you can call a javascript function, for before and after some occurance, like doing a "swap" You can check the status and go a different route if you so with. These are just a couple of options and does not add much complication to the overall htmx design. You still end up with much less javascript code this way.
yawaramin 1y ago
> this is probably the weakest part of it. This is not a 'part of' htmx. Htmx doesn't prescribe how you handle errors. You can easily respond with 400 or some other appropriate status code on error, and plug in to an htmx hook on the client side to handle it appropriately. Eg here's how I handle form validation errors with a 422 response status: https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg
calvinmorrison 1y ago
it's not a HTMX thing, i think others do that as well , or its a pattern i've seen a few times before. 200 -> the server is responding OK, with a body that contains an error.
lelanthran 1y ago
> Oof, an HTTP 200 OK response with a body that says the request actually was not OK. What's "oof" about it? The application layer should not inject error codes into the transport layer which is what HTTP is in this case. Do you also think that Apache/Nginx should be injecting codes into IP packets? If your application injects codes into the HTTP layer, how on earth does the client know whether the error originated at the application or at the reverse proxy/webserver?
- imiric 1y ago
  > The application layer should not inject error codes into the transport layer which is what HTTP is in this case. Huh? HTTP is an application layer protocol. It's perfectly acceptable for the application to return a non-200 status code when the request is invalid and can't be processed. There's a widely accepted status code for that exact scenario: 400 Bad Request. It informs the client that there was something wrong with their request, and in well-designed APIs, reading the response body would tell them the reason why. It would be wasteful for the client to always read the response and parse structured data to decide whether the request was successful (at the application level) or not. Status codes allow us to do that. That said, I've seen arguments for and against this practice, as sibling comments mention, and ultimately consistency and documentation are more important than semantics. The reason this line is blurry nowadays is because in the beginning web servers didn't contain complex logic. The web server was the application. Then came CGI scripts and application servers, and suddenly the application itself was making protocol-level decisions. The way this is typically structured in large applications is to have protocol-level abstractions that translate app-level errors into HTTP errors. But in small applications it's acceptable, though unsightly, to have HTTP logic mixed with business logic. > Do you also think that Apache/Nginx should be injecting codes into IP packets? Web servers do speak TCP/IP, so I'm not sure what your point is. Usually this is not something regular web apps need to be concerned with, but it's possible and sometimes desirable to introduce logic at the TCP or IP layer. There are proxy tools that work at both layer 4 and layer 7. > If your application injects codes into the HTTP layer, how on earth does the client know whether the error originated at the application or at the reverse proxy/webserver? By the status code, error message, and headers. An application would typically never return 502 Bad Gateway, a 301/302 redirect, or set headers like Cache-Control. By that same token, a reverse proxy/webserver would typically never override a 404 with a 200, or inject JSON error messages in the payload. The application ultimately decides the Content-Type of the response, which Content-Types it supports, and which headers it expects, so why shouldn't it also decide which status codes to return and which response headers to set? A gateway between it and the user can change or enhance this protocol, and specific gateways could be extracted to handle common things like authn/authz and load balancing, but the frontend gateway shouldn't override the message the application is sending (in typical circumstances). Both things can coexist with different responsibilities while speaking the same protocol. HTTP is flexible enough to support that. I'm curious, though: if you treat HTTP as the transport layer, what protocol does your application speak to the gateway? Is there some translation gateway that translates application-level semantics into HTTP ones?

SwiftyBug 1y ago

I think this debate is as old as time. I can see value in arguments both for and against this pattern. It's just a pattern. GraphQL does the same thing. As long as the consumers of that endpoint is aware of that behaviour I see no harm. In most cases, these endpoints serve only the frontend of the app. I would avoid doing something like that for a public API though.

deleted 1y ago
[deleted]

naasking 1y ago

> htmx is supposed to let you write semantic HTML, but it's obviously not semantic HTML/HTTP to respond HTTP 200 to incorrect user input. It's perfectly semantic HTML, it just doesn't have to be semantic HTTP (as in, you don't have to push semantics to the HTTP level, keep it at the HTML level). Thinking that HTTP status codes should be semantically meaningful means you're still thinking of htmx endpoints are or must be API endpoints. That's a mistake.

tacitusarc 1y ago
You are, however, communicating over HTTP. If the protocol conventions cannot be used due to limitations of the encoding, it is reasonable to question the encoding design. Another comment asserted HTMX can handle this, it just needs to be configured to do so. If that is the case, then I don’t see an actual issue.
- mtlynch 1y ago
  >Another comment asserted HTMX can handle this, it just needs to be configured to do so. If that is the case, then I don’t see an actual issue. You can, but it feels like you're sort of fighting the htmx library at that point. I do it, as it's the least bad option, but I generally find footguns with violating HTTP conventions (e.g., returning HTTP 200 for a bad request) or going outside the mainstream of a library (telling htmx that HTTP 400 can have a meaningful response body).

masfoobar 1y ago

I have not used the templ library so I cannot comment on this. However, as this is more an htmx query I will focus on this -- htmx supports returning other responses, and you can handle their behaviour if you choose to. At a basic level, validation/checks should be done on the server side. If there is a problem, you can return HTML. I dont see what the big deal is. On another note, you can call a javascript function, for before and after some occurance, like doing a "swap" You can check the status and go a different route if you so with. These are just a couple of options and does not add much complication to the overall htmx design. You still end up with much less javascript code this way.

yawaramin 1y ago

> this is probably the weakest part of it. This is not a 'part of' htmx. Htmx doesn't prescribe how you handle errors. You can easily respond with 400 or some other appropriate status code on error, and plug in to an htmx hook on the client side to handle it appropriately. Eg here's how I handle form validation errors with a 422 response status: https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg

calvinmorrison 1y ago

it's not a HTMX thing, i think others do that as well , or its a pattern i've seen a few times before. 200 -> the server is responding OK, with a body that contains an error.

lelanthran 1y ago

> Oof, an HTTP 200 OK response with a body that says the request actually was not OK. What's "oof" about it? The application layer should not inject error codes into the transport layer which is what HTTP is in this case. Do you also think that Apache/Nginx should be injecting codes into IP packets? If your application injects codes into the HTTP layer, how on earth does the client know whether the error originated at the application or at the reverse proxy/webserver?

imiric 1y ago
> The application layer should not inject error codes into the transport layer which is what HTTP is in this case. Huh? HTTP is an application layer protocol. It's perfectly acceptable for the application to return a non-200 status code when the request is invalid and can't be processed. There's a widely accepted status code for that exact scenario: 400 Bad Request. It informs the client that there was something wrong with their request, and in well-designed APIs, reading the response body would tell them the reason why. It would be wasteful for the client to always read the response and parse structured data to decide whether the request was successful (at the application level) or not. Status codes allow us to do that. That said, I've seen arguments for and against this practice, as sibling comments mention, and ultimately consistency and documentation are more important than semantics. The reason this line is blurry nowadays is because in the beginning web servers didn't contain complex logic. The web server was the application. Then came CGI scripts and application servers, and suddenly the application itself was making protocol-level decisions. The way this is typically structured in large applications is to have protocol-level abstractions that translate app-level errors into HTTP errors. But in small applications it's acceptable, though unsightly, to have HTTP logic mixed with business logic. > Do you also think that Apache/Nginx should be injecting codes into IP packets? Web servers do speak TCP/IP, so I'm not sure what your point is. Usually this is not something regular web apps need to be concerned with, but it's possible and sometimes desirable to introduce logic at the TCP or IP layer. There are proxy tools that work at both layer 4 and layer 7. > If your application injects codes into the HTTP layer, how on earth does the client know whether the error originated at the application or at the reverse proxy/webserver? By the status code, error message, and headers. An application would typically never return 502 Bad Gateway, a 301/302 redirect, or set headers like Cache-Control. By that same token, a reverse proxy/webserver would typically never override a 404 with a 200, or inject JSON error messages in the payload. The application ultimately decides the Content-Type of the response, which Content-Types it supports, and which headers it expects, so why shouldn't it also decide which status codes to return and which response headers to set? A gateway between it and the user can change or enhance this protocol, and specific gateways could be extracted to handle common things like authn/authz and load balancing, but the frontend gateway shouldn't override the message the application is sending (in typical circumstances). Both things can coexist with different responsibilities while speaking the same protocol. HTTP is flexible enough to support that. I'm curious, though: if you treat HTTP as the transport layer, what protocol does your application speak to the gateway? Is there some translation gateway that translates application-level semantics into HTTP ones?