@mmstick it seems to me that the choice to implement relationship is really up to the author(s) implementing the JSONAPI response. In my experience with the spec it seems that relationships are exposed as often as possible. Included resources are a different matter.

Either way, I do feel like modern implementations of this crate allow you to choose if/when you expose relationships on the primary resource objects in the document. If you feel this is not the case can you provide some example of how this crate is not generating according to your expectations?

I have a model that has an optional property. To take an example from the unit tests, imagine a book with an optional forward.

#[derive(Debug, PartialEq, Serialize, Deserialize)]
struct Book {
    id: String,
    title: String,
    forward: Option<Chapter>,
    first_chapter: Chapter,
    chapters: Vec<Chapter>
}
jsonapi_model!(Book; "books"; has one forward, first_chapter; has many chapters);

Not every book, has a forward but some do. I would like for the library to support this. Today we get:

error[E0277]: the trait bound `std::option::Option<Chapter>: jsonapi::model::JsonApiModel` is not satisfied
  --> tests/model_test.rs:28:1
   |
28 | jsonapi_model!(Book; "books"; has one forward, first_chapter; has many chapters);
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `jsonapi::model::JsonApiModel` is not implemented for `std::option::Option<Chapter>`
   |
   = note: required by `build_has_one`
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

So a few questions:

1. I'm thinking it should follow a pattern similar the crate::array and add a crate::optional
2. Do we want a different syntax than has one for optionals?