HTTP Resource

What it looks like

One http_adapter block turns a REST endpoint into a full Avo resource:

class Avo::Resources::Author < Avo::BaseResource
  self.http_adapter = {
    endpoint: "https://api.example.com/authors",
    headers: { "Authorization" => "Bearer " + ENV["API_TOKEN"] },
    parse_collection: ->(response) { response.parsed_response["data"] },
    parse_record: ->(response) { response.parsed_response["author"] },
    parse_count: ->(response) { response.parsed_response["meta"]["total"] }
  }

  def fields
    field :id, as: :id
    field :name, as: :text
    field :email, as: :text
  end
end

What you get

• Stand up a full admin for any REST API in one command, bin/rails generate avo:resource Name --http, with no table or model behind it
• Manage records that never touch your database: point http_adapter at the endpoint and the upstream API behaves like a normal Avo resource
• Render messy upstream payloads cleanly by reshaping JSON to your fields with parse_collection, parse_record, and parse_count
• Work against authenticated, paginated APIs out of the box, pass tokens through headers and build query strings from controller params
• Edit a remote record the way you edit a local one, with full create, read, update, and delete over HTTP through the built-in HTTParty client
• Fail gracefully when the upstream API is down: raise Avo::HttpError and the user sees a flash message instead of a stack trace

Why it pays off

• Go from an API endpoint to a working admin in a few minutes, instead of building a client, pagination, and CRUD plumbing over a sprint.
• Every Avo release makes it better: the HTTParty client, request timeouts, and error handling stay maintained and keep working through upgrades, without you patching them.
• Your API-backed records reuse the same Avo resource, field, and action machinery, so they look and behave like the rest of your app, not a bolted-on one-off.