I'm seeing an issue where read_only attributes aren't in the read_only metadata if e.g. I have an EventsController that uses a serializer named BasicEventSerializer (or anything that's not the default EventSerializer).

Looks like it's because RenderJsonMeta::MetadataReadOnly only looks for the default serializer:

class EventsController < APIController
  handles :show

  def show
    render(
      json: self.record = model.find(params[primary_key]),
      serializer: BasicEventSerializer
    )
  end
end

class BasicEventSerializer < ActiveModel::Serializer
  embed :ids

  attributes :id
  read_only :created_at
end

{
  "event": {
    "id": 24522,
    "created_at": "2014-11-24T16:02:08.383Z"
  },
  "meta": {
    "event": {
      "read_only": [],
      "nested_resources": []
    }
  }
}

class Resource < Daylight::API
  belongs_to :owner
end

ActiveResource supports (rails/activeresource#50) resolving a belongs_to association via a foreign key:

r = Resource.first 
=> {
  ...
  "owner_id": 42
}

or through the attribute name:

r = Resource.first 
=> {
  ...
  "owner": {
    ...
  }
}

It looks like Daylight is failing on the latter since it expects the foreign key to be present.

Relevant line:

It uses Daylight::API.version to construct examples which only exists in the client gem.

For example:

API::V1::Post.find(1)
API::V2::Comment.find(2)

Since this is an edge case for development or migration purposes.
Associated classes will adopt the version of the parent (unless we offer an option to fall back).

Will need to set_prefix on a per class bases through inherited.

Need to look at this and create issues for each:
https://github.com/interagent/http-api-design

• Foundations
  • Require TLS
  • Version with Accepts header
  • Support caching with Etags
  • Trace requests with Request-Ids
  • Paginate with ranges
• Requests
  • Return appropriate status codes
  • Provide full resources where available
  • Accept serialized JSON in request bodies
  • Use consistent path formats
  • Downcase paths and attributes
  • Support non-id dereferencing for convenience
  • Minimize path nesting
• Responses
  • Provide resource (UU)IDs
  • Provide standard timestamps
  • Use UTC times formatted in ISO8601
  • Nest foreign key relations
  • Generate structured errors
  • Show rate limit status
  • Keep JSON minified in all responses
• Artifacts
  • Provide machine-readable JSON schema
  • Provide human-readable docs
  • Provide executable examples
  • Describe stability

From this list here are the identified todos:

• I know ~~~request ID and~~~ pagination (ranges) definitely for 1.0.0

• Examine how to implement: Etags, Caching (plugin), Rate Limiting (plugin) mechanisms

• For "Use consistent path formats" -- we could add a mechanism for "actions"

• Patch Rails to allow dashes in routes, converting them to underscores in controller lookup.

• Return full resource in update and delete actions; ensure ActiveResource doesn't complain

• Consider adding created_at, updated_at as default read_only attributes

• Support non-id dereferencing for convenience, for example /zones/ewr1.json:

  class ZoneController < APIController
    find_by :code, :uuid
  end

• Nest foreign key relations should be investigated.

• Consider adding id, url to structured errors; url points back to auto-generated doc in the API

Does it make sense to have model-based association on belongs_to and has_one like they are available on has_many

class API::V1::Post < Daylight::API
  has_one :blog, through: :association
  has_one :company, through: association
  has_many :comments, through: association # only one currently supported
end

List of endpoints under the 'API' heading.

For example:

API::V1::Post.find(1)
API::V2::Comment.find(2)

Since this is an edge case for development or migration purposes.
Associated classes will adopt the version of the parent (unless we offer an option to fall back).

Will need to set_prefix on a per class bases through inherited.

We're currently pulling the models as anything that subclasses ActiveRecord::Base which isn't always the case.

From a client POV is there a difference between remoted and associated? Can they be consolidated.

For example

GET /v1/posts/1/comments.json # associated
GET /v1/posts/1/top_comments.json # remoted (collection)
GET /v1/posts/1/statistics.json # remoted (single record)

We can detect if it's a collection vs. a single record. (Maybe ActiveResource already does?)
In fact, we could use has_many and has_one/belongs_to to implement remoted instance methods from the client-side

Add collection version of remote methods

Maybe remoted is only for class level methods? (how are they different from scopes?)

GET /v1/posts/by_popularity

We do have scopes and instance-level remote methods but there could be a case where a collection (class-level) based remote method would be useful.

class Post < ActiveRecord::Base
  def self.by_popularity
     order_by(:vists)
  end
end

This by_popularity method is a trivial example (tht could be a scope -- uh, from the client POV, why wouldn't it just be a scope?) but imagine a query that is much more computationally expensive across all Posts

Should we allow refinements on remote methods like we do with associations.

Given a Post

class Post < ActiveRecord::Base
  has_many :comments
  def top_comments
     comments.order_by(:like_count)
  end
end

And its Comment:

class Comment < ActiveRecord::Base
   scope :edited, -> { where.not(updated_at: nil) }
end

Could we?

Post.first.top_comments.edited 

As the title says. I'd be great if this gem supported rails 5 since rails 4.1 is already EOL.