Lets start of with, is there a difference between the const value vs const reference?

No. Not any practical difference at least. AFAIK behind the scenes, the const reference is just a const value that Rust automatically creates a reference to. So it’s just a matter of preference or what makes sense for your case.

1. Since my functions always take a reference, is there any advantage to any of them. References are read-only, but since it’s const it probably doesn’t matter. What is prefered?

I think I need to see an example of the function (or at least the signature) to give any concrete advice. It really depends on what you’re doing and what the function is.

2. I know String does allocations, while &str is a string slice or something which may be on the stack. Do I not end up making any allocations in this case since stucts are on the stack by default, and only hold the pointers to a string “slice”. Especially given how they are made in this case.

Okay so there’s multiple things to unpack here. First of all, &str is a string slice, as you say. It is a “fat pointer”, as all slices are, with 2 components: A pointer to the data and a length.

However, &str does not say anything about whether or not the data that it points to or even the &str itself (pointer + length) is on the stack or not. The pointer inside the &str may point anywhere and there’s no guarantee that even the &str itself is on the stack (e.g. a Box<&str> is a &str on the heap and the pointer inside that &str could point anywhere).

When you write a string literal like "Hello world!", it is a &'static str slice, where the &str itself (pointer + length) exists on the stack and the data that it points to is memory inside your final executable binary. But you can get &str’s from elsewhere, like a &str that refers to memory on the heap that doesn’t have a 'static lifetime.

So when you write a string literal like you are in your consts there, you are not allocating any memory on the heap (in fact it is impossible to allocate memory on the heap in a const context). All you’re doing is adding a bit of string data to your final executable and that’s what the &str points to. To allocate, you would need to use a String.

3. Is structs with references like this okay, this Page is constant but I’m going to make many “Pages” later based on the pages my blog has, as well as some other endpoints of course.

If all of your Pages are constant and you will write them out like this with literal strings, it’s not like there is any “problem”. However, you’ll only be able to make Pages that can be defined at compile-time. Maybe that’s fine if all your pages are pre-defined ahead of time and doesn’t use any dynamic values or templating? If so, you can keep it like this in principle. You could even write the pages in a separate file and use the include_str! macro to import them as a &'static str as if you had written it out directly in your code.

If you need just some Pages to have dynamic content, then you’ll need to either use a String (which would make all of them heap-allocated) or you could use a Cow (clone-on-write pointer) which is an enum that can either be borrowed data like a &'static str or owned data like String. Using Cow you could allow the static pages to not allocate while the dynamic ones do.

4. If the struct is cloned, is the entire string as well, or just the pointer to the string slice? I assume it does copy the entire string, since to the best of my knowledge a &str does not do any reference counting, so deleting a &str means deleting it’s content, not just the reference. Since that is the case, a clone will also copy the string.

No, cloning a &str does not clone the underlying text data. You can see this via a simple program:

fn main() {
    let s1 = "Example text";
    let s2 = s1.clone();
    
    println!("{s1:p}");
    println!("{s2:p}");
}

The :p format specifier is the “pointer” specifier and will print the pointer of the string slice. If you run this, you’ll see that it prints the exact same pointer twice - i.e. both s1 and s2 are pointing to the exact same data (which only exists once).

No reference counting is needed. Remember, Rust keeps track of reference lifetimes at compile-time. If you clone a &'a str then the clone is also a &'a str. This is fine, it’s just another reference to the same string data and of course it has the same lifetime because it will be valid for just as long. Of course it’s valid for just as long, it’s pointing to the same data after all.

Note that mutable references cannot be cloned, as that would allow multiple mutable references to the same data and that’s not allowed.

Note that dropping (“deleting” is not a term used in Rust) a &str does not free the underlying memory. It is just a reference after all, it doesn’t own the memory underneath.

5. I am contemplating adding a “body” string to my Page struct. These string will of course be large and vary depending on the page. Naturally, I do not want to end up copying the entire body string every time the Page is cloned. What is the best course here, it kind of depends on the previous question, but is an Arc the solution here? There is only reading to be done from them, so I do not need to worry about any owner holding it.

If the body is a &str, then it will only clone the reference and the string data itself will not be copied, so this shouldn’t be an issue. But remember as I said above that this might only be true if your pages are indeed defined ahead-of-time and don’t need dynamic memory allocation.

I can give more concrete advice if you give more code and explain your use case more thoroughly (see also XY problem).