bullet_train-api 1.1.13 → 1.1.14

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: a26bfba5a9e08beab9b2e9ef020751627ba9f5e622708f74bf44798ea903434b
-  data.tar.gz: b40893d54092bb315a343891b69a0cc84a651c30775bd8840f0a3b917b791136
+  metadata.gz: d41bf508cee51978fb613e1eb742893560df176131046f2013c78424de30022a
+  data.tar.gz: 260a8f510030718dbdd1cb1683a2416b83720c524c91fc5a4bb2b5549d8f4341
 SHA512:
-  metadata.gz: 2794b6b2cb7574361e60c9ef1e26b9cf1cf142c557f6bbebb60fe724b2c7c7ea0857b036ad432c0cfee1d9e286508db49ea63822d06ea71a0566407f60cbd082
-  data.tar.gz: 2b4f042745a52886ba79973b159fe3a70b216f55591d537746d1a0a62365454ad6be01f132ed198665b03ed24f85022eeecd7fa5788555ce2dccdd52c5f1ae03
+  metadata.gz: ba5bdc2be5f38f9f7812624253cd15a09b24f2ad7433885a0c6cc17b89ac2dfbc5030e007786db0db7cf4958e3d8bb93d014b5ac0aa89d478c57b83084a0b62e
+  data.tar.gz: 4331563acc4e405b7aee50cf7b03afa8926c8c23d4854e8f6d0412ae9aa3e855bb2081f2053fbdbb8cc9afe0338d476d4d050e92f89b88197d44db0f2aa1731f

data/docs/api/versioning.md

@@ -0,0 +1,63 @@
+# API Versioning
+Bullet Train's API layer is designed to help support the need of software developers to evolve their API over time while continuing to maintain support for versions of the API that users have already built against.
+
+## What is API versioning?
+By default, Bullet Train will build out a "V1" version of your API. The version number is intended to represent a contract with your users that as long as they're hitting `/api/v1` endpoints, the structure of URLs, requests, and responses won't change in a way that will break the integrations they've created.
+
+If a change to the API would break the established contract, we want to bump the API version number so we can differentiate between developers building against the latest version of the API (e.g. "V2") and developers who wrote code against the earlier version of the API (e.g. "V1"). This allows us the opportunity to ensure that older versions of the API continue to work as previously expected by the earlier developers.
+
+## When should you take advantage of API versioning?
+You want to bump API versions as sparingly as possible. Even with all the tooling Bullet Train provides, maintaining backwards compatibility of older API versions comes at an ongoing cost. Generally speaking, you should only bump your API version when a customer is already using an API endpoint and you're making changes to the structure of your domain model that are not strictly additive and will break the established contract.
+
+Importantly, if the changes you're making to your domain model are only additive, you don't need to bump your API version. Users shouldn't care that you're adding new attributes or new endpoints to your API, just as long as the ones they're already using don't change in a way that is breaking for them.
+
+## Background
+By default, the following components in your API are created in versioned namespaces:
+
+ - API controllers are in `app/controllers/api/v1` and live in an `Api::V1` module.
+ - JSON views are in `app/controllers/api/v1`.
+ - Routes are in `config/routes/api/v1.rb`.
+ - Tests are in `test/controllers/api/v1` and live in an `Api::V1` module.
+
+> It's also impotant to keep in mind that some dependencies of your API and API tests like models, factories, and permissions are not versioned, but as we'll cover later, this is something our approach helps you work around.
+
+## Bumping Your API Version
+
+⚠️ You must do this _before_ making the breaking changes to your API.
+
+If you're in a situation where you know you need to bump your API version to help lock-in a backward compatible version of your API, you can simply run:
+
+```
+rake bullet_train:api:bump_version
+```
+
+> TODO This Rake task doesn't exist yet.
+
+## What happens when you bump an API version?
+When you bump your API version, all of the files and directories that are namespaced with the API version number will be duplicated into a new namespace for the new API version number.
+
+For example, when bumping from "V1" to "V2":
+
+ - A copy of all the API controllers in `app/controllers/api/v1` are copied into `app/controllers/api/v2`.
+ - A copy of all the JSON views in `app/views/api/v1` are copied into `app/views/api/v2`.
+ - A copy of all the routes in `config/routes/api/v1.rb` are copied into `config/routes/api/v2.rb`.
+ - A copy of all the tests in `test/controllers/api/v1` are copied into `test/controllers/api/v2`.
+
+We also bump the value of `BulletTrain::Api.current_version` in `config/initializers/api.rb` so tools like Super Scaffolding know which version of your API to update going forward.
+
+## How does this help?
+As a baseline, keeping a wholesale copy of the versioned API components helps lock in their behavior and protect them from change going forward. It's not a silver bullet, since unversioned dependencies (like your model, factories, and permissions) can still affect the behavior of these versioned API components, but even in that case these copied files give us a place where we can implement the logic that helps older versions of the API continue to operate even as unversioned components like our domain model continue changing.
+
+### Versioned API Tests
+By versioning our API tests, we lock in a copy of what the assumptions were for older versions of the API. Should unversioned dependencies like our domain model change in ways that break earlier versions of our API, the test suite will let us know and help us figure out when we've implemented the appropriate logic in the older version of the API controller to restore the expected behavior for that version of the API.
+
+## Advanced Topics
+
+### Object-Oriented Inheritance
+In order to reduce the surface area of legacy API controllers that you're maintaining, it might make sense in some cases to have an older versioned API controller simply inherit from a newer version or the current version of the same API controller. For example, this might make sense for endpoints that you know didn't have breaking changes across API versions.
+
+### Backporting New Features to Legacy API Versions
+Typically we'd recommend you use new feature availability to encourage existing API users to upgrade to the latest version of the API. However, in some situations you may really need to make a newer API feature available to a user who is locked into a legacy version of your API for some other endpoint. This is totally fine if the feature is only additive. For example, if you're just adding a newer API endpoint in a legacy version of the API, you can simply have the new API controller in the legacy version of the API inherit from the API controller in the current version of the API.
+
+### Pruning Unused Legacy API Endpoints
+Maintaining legacy endpoints has a very real cost, so you may choose to identify which endpoints aren't being used on legacy versions of your API and prune them from that version entirely. This has the effect of requiring existing API users to keep their API usage up-to-date before expanding the surface area of usage, which may or may not be desirable for you.

data/docs/api.md

@@ -0,0 +1,106 @@
+# REST API
+We believe every SaaS application should have an API and [webhooks](https://github.com/bullet-train-co/bullet_train-base/blob/main/docs/webhooks/outgoing.md) available to users, so Bullet Train aims to help automate the creation of a production-grade REST API using Rails-native tooling and provides a forward-thinking strategy for its long-term maintenance.
+
+## Background
+Vanilla Rails scaffolding actually provides simple API functionality out-of-the-box: You can append `.json` to the URL of any scaffold and it will render a JSON representation instead of an HTML view. This functionality continues to work in Bullet Train, but our API implementation also builds on this simple baseline using the same tools with additional organization and some new patterns. 
+
+## Goals
+
+### Zero-Effort API
+As with vanilla Rails scaffolding, Super Scaffolding automatically generates your API as you scaffold new models, and unlike vanilla Rails scaffolding, it will automatically keep it up-to-date as you scaffold additional attributes onto your models.
+
+### Versioning by Default
+By separating out and versioning API controllers, views, routes, and tests, Bullet Train provides [a methodology and tooling](/docs/api/versioning.md) to help ensure that once users have built against your API, changes in the structure of your domain model and API don't unexpectedly break existing integrations. You can [read more about API versioning](/docs/api/versioning.md).
+
+### Standard Rails Tooling
+APIs are built using standard Rails tools like `ActiveController::API`, [Strong Parameters](https://api.rubyonrails.org/classes/ActionController/StrongParameters.html), `config/routes.rb`, and [Jbuilder](https://github.com/rails/jbuilder). Maintaining API endpoints doesn't require special knowledge and feels like regular Rails development.
+
+### Outsourced Authentication
+In the same way we've adopted [Devise](https://github.com/heartcombo/devise) for best-of-breed and battle-tested authentication on the browser side, we've adopted [Doorkeeper](https://github.com/doorkeeper-gem/doorkeeper) for best-of-breed and battle-tested authentication on the API side.
+
+### DRY Authorization Logic
+Because our API endpoints are standard Rails controllers, they're able to leverage the exact same [permissions definitions and authorization logic](https://github.com/bullet-train-co/bullet_train-base/blob/main/docs/permissions.md) as our account controllers.
+
+## Structure
+Where vanilla Rails uses a single controller in `app/controllers` for both in-browser and API requests, Bullet Train splits these into two separate controllers, one in `app/controllers/account` and another in `app/controllers/api/v1`, although a lot of logic is shared between the two.
+
+API endpoints are defined in three parts:
+
+1. Routes are defined in `config/routes/api/v1.rb`.
+2. Controllers are defined in the `app/controllers/api/v1` directory.
+3. Jbuilder views are defined in the `app/views/api/v1` directory.
+
+## "API First" and Supporting Account Controllers
+As previously mentioned, there is a lot of shared logic between account and API controllers. Importantly, there are a couple of responsbilities that are implemented "API first" in API controllers and then utilized by account controllers.
+
+### Strong Parameters
+The primary definition of Strong Parameters for a given resource is defined in the most recent version of the API controller and included from there by the account controller. In account controllers, where you might expect to see a Strong Parameters definition, you'll see the following instead:
+
+```ruby
+include strong_parameters_from_api
+```
+
+> This may feel counter-intuitive to some developers and you might wonder why we don't flip this around and have the primary definition in the account controller and have the API controller delegate to it. The answer is a pragmatic one: creating and maintaining the defintion of Strong Paramters in the API controller means it gets automatically frozen in time should you ever need to [bump your API version number](/api/docs/versioning.md). We probably _could_ accomplish this if things were the other way around, but it wouldn't happen automatically.
+
+If by chance there are additional attributes that should be permitted or specific logic that needs to be run as part of the account controller (or inversely, only in the API controller), you can specify that in the controller like so:
+
+```ruby
+def permitted_fields
+  [:some_specific_attribute]
+end
+
+def permitted_arrays
+  {some_collection: []}
+end
+
+def process_params(strong_params)
+  assign_checkboxes(strong_params, :some_checkboxes)
+  strong_params
+end
+```
+
+### Delegating `.json` View Rendering on Account Controllers
+
+In Bullet Train, when you append `.json` to an account URL, the account controller doesn't actually have any `.json.jbuilder` templates in its view directory within `app/views/account`. Instead, by default the controller is configured to delegate the JSON rendering to the corresponding Jbuilder templates in the most recent version of the API, like so:
+
+```ruby
+# GET /account/projects/:id or /account/projects/:id.json
+def show
+  delegate_json_to_api
+end
+```
+
+## Usage Example
+First, provision a platform application in section titled "Your Applications" in the "Developers" menu of the application. When you create a new platform application, an access token that doesn't automatically expire will be automatically provisioned along with it. You can then use the access token to hit the API, as seen in the following Ruby-based example:
+
+```ruby
+require 'net/http'
+require 'uri'
+
+# Configure an API client.
+client = Net::HTTP.new('localhost', 3000)
+
+headers = {
+  "Content-Type" => "application/json",
+  "Authorization" => "Bearer GfNLkDmzOTqAacR1Kqv0VJo7ft2TT-S_p8C6zPDBFhg"
+}
+
+# Fetch the team details.
+response = client.get("/api/v1/teams/1", headers)
+
+# Parse response.
+team = JSON.parse(response.body)
+
+# Update team name.
+team["name"] = "Updated Team Name"
+
+# Push the update to the API.
+# Note that the team attributes are nested under a `team` key in the JSON body.
+response = client.patch("/api/v1/teams/1", {team: team}.to_json, headers)
+```
+
+## Advanced Topics
+ - [API Versioning](/docs/api/versioning.md)
+
+## A Note About Other Serializers and API Frameworks
+In early versions of Bullet Train we made the decision to adopt a specific serialization library, [ActiveModelSerializers](https://github.com/rails-api/active_model_serializers) and in subsequent versions we went as far as to adopt an entire third-party framework ([Grape](https://github.com/ruby-grape/grape)) and a third-party API specification ([JSON:API](https://jsonapi.org)). We now consider it out-of-scope to try and make such decisions on behalf of developers. Support for them in Bullet Train applications and in Super Scaffolding could be created by third-parties.

data/lib/bullet_train/api/version.rb

@@ -1,5 +1,5 @@
 module BulletTrain
   module Api
-    VERSION = "1.1.13"
+    VERSION = "1.1.14"
   end
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: bullet_train-api
 version: !ruby/object:Gem::Version
-  version: 1.1.13
+  version: 1.1.14
 platform: ruby
 authors:
 - Andrew Culver
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2022-11-08 00:00:00.000000000 Z
+date: 2022-11-16 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: standard
@@ -187,6 +187,8 @@ files:
 - config/locales/en/platform/access_tokens.en.yml
 - config/locales/en/platform/applications.en.yml
 - config/routes.rb
+- docs/api.md
+- docs/api/versioning.md
 - lib/bullet_train/api.rb
 - lib/bullet_train/api/engine.rb
 - lib/bullet_train/api/strong_parameters_reporter.rb