Additional error types!

The GenericJSONAPIError makes it easy to fit any old structure to the requirements for the JSONAPIError protocol.

The BasicJSONAPIError provides out-of-box support for parsing most of the fields the JSON:API Spec says might be available on error objects. These fields are all optional because the Spec does not require any of them to be present.

More than likely, transitioning from use of UnknownJSONAPIError to BasicJSONAPIError<String> (or perhaps specialized on Int) is an easy non-breaking move for most codebases that gets you more information about the errors being parsed.

Add Include10

Add Include10 type that allows you to include 10 different types of resources with a JSONAPI.Document.

Change CocoaPods spec name and add new way to access attributes

New with this version is dynamicMemberLookup of JSON:API attributes. You can still access a model's attributes as model[\.attributeName] but now you can also just write model.attributeName. Note this applies to attributes, not relationships.

⚠️ Breaking Changes ⚠️

• Swift Tools version 5.1 is required for SPM
• Swift 5.1 is required for the dynamicMemberLookup feature allowing more concise access to JSON:API attributes.
• The PodSpec name of this library has changed to avoid a name conflict with a different JSONAPI library -- the module name remains the same, so your imports don't change, just your pod file dependency declaration.

Sparse Fieldset support and first major version release.

This release adds support for encoding sparse fieldsets of ResourceObjects.

⚠️ Breaking Changes ⚠️

The following breaking changes were mostly made to support sparse fieldsets as an encoding-only feature.

• JSONAPI.Include went from guaranteeing Codable to only guaranteeing Encodable, although conforming types within the library are still conditionally Decodable.
• The JSONPoly typealias was replaced by EncodableJSONPoly and only guarantees Encodable.
• AppendableResourceBody was renamed Appendable and does not guarantee conformance to ResourceBody anymore (but ManyResourceBody conforms to both ResourceBody and Appendable).
• MaybePrimaryResource was renamed OptionalPrimaryResource.

CocoaPods fixes

0.31.1

bump podspec version after two cocoapods fixes.

Allow relationship object omission if all relationships are optional

⚠️ Breaking-ish change ⚠️

If you had previously come to rely on the fact that the only way to allow omission of the relationships key was to create the Relationships = NoRelationships type alias, this change will be breaking. Still, because the JSON:API Spec allows for omission of the relationships key unconditionally, this change does bring the library more in line with the spec and I think this library's usability improves.

A lot of renaming to better align with JSON:API spec language.

⚠️ Breaking change ⚠️

Pretty large renaming effort to better align the type names in this library with the names used by the JSON:API Spec. I think this will ultimately make it much easier to adopt this library given prior knowledge of the Spec. There are no substantive feature changes here, just renaming.

For the most part, renaming is of the pattern: If it used to be Entity then it is now ResourceObject

Change spelling of "direct" subscript overload on Entity.

⚠️ Breaking change ⚠️

Take the following definitions:

enum TestDescription: EntityDescription {
  static var jsonType: String { return "test" }

  typealias Relationships = NoRelationships

  struct Attributes: JSONAPI.Attributes {
    let normal: Attribute<String>
    var direct: String { return normal.value }
  }
}
typealias Test = Entity<TestDescription, NoMetadata, NoLinks, String>

let test: Test = ...

You used to be able to access both attributes using the default subscript:

let one: String = test[\.normal]
let two = test[\.direct]

However, in the case of test[\.normal], the code was ambiguous unless you explicitly asked for a String (the compiler would not know if you wanted the String or the whole Attribute<String>).

That is what has changed. There is no more ambiguity, but now the direct access subscript has a new spelling:

let one = test[\.normal]
let two = test[direct: \.direct]

It may seem like the verbosity of the code has just moved from one place to another, but the much less common feature (direct access) has taken on the burden.

Default to Swift version 5.0

⚠️ Breaking Change ⚠️
Requires Swift Tools version 5.0 (shipped with Xcode 10.2)

Add CocoaPods support

See README update for details.