3

As we know HTTP codes are used in HTTP response. Usually with this code we can have an idea about what happened. For example if I make a get request and I obtain a 404 I can figure out that the resource that I requested doesn't exist on the server side.

Suppose that I want to encode the status of an object in the DB. For example let's say that if the object exist but some data are missing (a specific field for example) I want to save it in my DB but express the status of the object with a column. This need to be an integer (suppose it is a constraint). I would go for 206 (partial content in HTTP).

From a code point of view suppose we have an enum to express the various possible status as this one:

public enum ValidationStatus {

    OK(HttpStatus.OK.value()),
    PARTIAL(HttpStatus.PARTIAL_CONTENT.value()),
    ...

    private final Integer code;
    ...

When someone reads the code, it seems that HTTP is involved in some way. But in this case it’s not. I'm reusing the HTTP status to represent something else.

I saw that in a project but I'm not sure about if this is a good practise. It’s like mixing things for me. I'm using something created for HTTP to represent something else.

Do you think that it is acceptable?

EDIT: to be more precise my was just an example of reusing HTTP code in other context. Actually in the DB is stored the string value (in this case PARTIAL) but in this microservices application, the services communicate with messages and in these messages you find the integer. When for example an object is in the status PARTIAL a notification is send to another service as if it is a sort of error. This question arose when I was running some tests, and in the log I so this: "ERROR 206 PARTIAL". I saw this and the HTTP 206 status came into my mind. After that I discovered the use of this code in the application and so the enum class. My initial confusion brought me to ask this question. The I discovered that HTTP was not involved at all.

7
  • Two things can be similar without needing to be related, and arbitrary values are inherently at your discretion. I'm not sure how much more specific of an answer you're looking for here.
    – Flater
    Sep 15, 2021 at 12:42
  • 1
    > Suppose that I want to encode the status of an object in the DB Why do you want to do that? Why should the system calling your API care what's in the DB? Don't they just care about what they can get back in the response?
    – bdsl
    Sep 15, 2021 at 13:28
  • 1
    I don't know why someone downvoted this. Seems like a perfectly fine question to me. So I upvoted it.
    – Blake
    Sep 15, 2021 at 17:43
  • 2
    This is a misunderstanding of what the 206 status means. You wouldn't be reusing the status. You would be redefining it. Related StackOverflow question: What does the HTTP 206 Partial Content status message mean and how do I fully load resources? Sep 15, 2021 at 18:35
  • This reminds me of the way that XML namespaces are declaring using strings that look exactly like internet endpoints. There have been a few times that engineers on my team were mixed up because of this, e.g. when looking through logs. I can see why the designers of the format decided to do it that way, but sometimes I wish namespaces were a different format entirely.
    – John Wu
    Sep 16, 2021 at 0:20

3 Answers 3

10

I would advise against it. The most likely result is that you will create confusion with future developers/maintainers.

  • You are using the codes outside of the context of HTTP, so you will probably get questions about what happened to the status codes with values 0 to 199. In the database, the fact that the codes begin at 200 does not have any inherent meaning.
  • As mentioned in another answer, the HTTP status codes may not be specific enough, so you would have to invent new values that you have to give a meaning yourself (and which may conflict with future HTTP status codes).

After you have had to invent your first application-specific status code, any advantage you may have had previously that the values were 'well known' and didn't need to be documented by you is now gone as well and there is no reason left not to do the conventional thing and count your status values from 1 (or 0).

8
  • 3
    Even in the context of HTTP there are really just handful of codes that are well understood (200 - here, 301/302 - there, 404 - not here, 500 - everything is broken, and maybe 401/403 - tell me who you are). All other codes are rare enough that most people will have to dig out the definition and even then expect incorrect usage anyway... Sep 16, 2021 at 6:01
  • After you have had to invent your first application-specific status code, any advantage you may have had previously that the values were 'well known' is now gone - why? I can still easily remember those handful of codes that we re-used, and for others - I'd have to look them up each time I forget. Sep 16, 2021 at 6:10
  • 1
    @StanislavBashkyrtsev because if they look like HTTP codes they will be used as HTTP codes whether one accounted for it or not. And the once that are not valid HTTP codes will randomly cause interesting day long investigations... Sep 16, 2021 at 6:54
  • @AlexeiLevenkov, well that's quite a stretch.. And I'm pretty sure Bart was talking about something else. Sep 16, 2021 at 7:11
  • @StanislavBashkyrtsev, it is not that much of a stretch.If you intentionally style your status codes after the HTTP codes, then you probably also refer to the HTTP documentation for the meaning of them (at least until you have a case that isn't covered by an HTTP code). And then that will become the primary source of information, even when it is no longer fitting. Sep 16, 2021 at 7:54
2

In a multi-tiered architecture, the business layer should have no knowledge of the transport. That allows the same code to run in a web service, on a desktop, or on a phone. Or possibly in your thermostat. Let me give you a practical example of this.

Let's say you want to use HTTP status codes in your business layer, so your developer adds a dependency to System.Web. Now you're going to have to deploy System.Web everywhere your business logic is going to live, including places where it might make absolutely no sense, or where it does make sense to have a System.Web but your business layer was built with the wrong version. When that happens, you may have to version your web platform and business objects in lockstep, which reduces your deployment agility.

Your business layer should define its own enumeration for its own business concepts. If you like, its numeric values can "coincidentally" be 200 for OK and 404 for not found, but it should be a list of codes in its own right that you own.

-4

This seems like a very nice idea. It's great when we can re-use ideas from other areas - this way we can reuse our knowledge instead of learning purely new concepts in each context.

However HTTP codes are often vague and not precise, you won't be able to express many of your custom statuses with HTTP. So I'd go like this:

  1. If the status clearly resembles an HTTP response code - re-use it
  2. If your status is not entirely consistent with HTTP - come up with your own code. Otherwise it'll be confusing.

A possible downside: if your statuses are always sequential, then sometimes it's useful to use their integer values to check if we're passed some status or not. HTTP codes won't allow this. On the other hand - such needs aren't that common and you may create additional "stage" attribute to your enum for that.

To downvoters - please comment on why you think it's a bad idea. Describe what harm do you think will come from re-using HTTP codes.

5
  • 1
    HTTP status codes aren't really designed for this. Sep 15, 2021 at 20:25
  • 1
    This looked good up to the point of recommending defining custom status codes. That could put your application in conflict with future versions of the HTTP protocol. Then you are right back in the territory @Zach describes in his answer. Sep 15, 2021 at 23:03
  • @GregBurghardt, Zach's answer is offtopic, he misunderstood the question. This question is NOT about HTTP. Sep 16, 2021 at 5:16
  • @RobertHarvey, what do you mean they are not "designed" for this? It's your app design that we're discussing, not HTTP. You can't break HTTP by re-using its numbers elsewhere. Of course they won't cover all your custom statuses of your custom app. But whenever there's an intersection, there's no harm in re-using the same numbers. After all, the database won't care which number you keep in your column. You give meaning to the number. And if that number is easier to remember just because it's coming from some well known spec - that's great, this just simplifies the memorization of those codes. Sep 16, 2021 at 5:19
  • 1
    @StanislavBashkyrtsev: You cannot discuss HTTP without also discussing HTTP codes. Sep 16, 2021 at 11:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.