rack-service_api_versioning 0.1.0 → 0.1.1
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/README.md +2 -2
- data/lib/rack/service_api_versioning/version.rb +1 -1
- metadata +2 -2
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: c8a7c02ecbb6d134d8cc556f3f19b7ee526fded3
|
4
|
+
data.tar.gz: 1ab7eccd98650977cc3a39866470336b0e693bd8
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: ab4f032d06dc8b4495ffb954377acd371388e10ef16610ca8fe3fb6649fa9f77d289a7b0f8ed2d364cca2b5d450276047616f56fab00692f05a1495ca46b522e
|
7
|
+
data.tar.gz: 4067b5e0c9e8f1584c28844213c105b1f1426de4c08d9b370a8e8cc8560e71b9a2fe10d4cb7ef22af42e10a02464ea7084d49fbb09fa354c50a11cb1f5e89b52
|
data/README.md
CHANGED
@@ -1,6 +1,6 @@
|
|
1
1
|
<h1>Rack::ServiceApiVersioning</h1>
|
2
2
|
|
3
|
-
[![Join the chat at https://gitter.im/rack-service_api_versioning
|
3
|
+
[![Join the chat at https://gitter.im/jdickey/rack-service_api_versioning](https://badges.gitter.im/jdickey/rack-service_api_versioning.svg)](https://gitter.im/jdickey/rack-service_api_versioning?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
|
4
4
|
|
5
5
|
This Gem implements three Rack middleware components that, together, enable possibly multiple API Versions of one or more Component Services to be active at the same time. Incoming requests for a service specify their version requirements, if any, with an `Accept` HTTP header.
|
6
6
|
|
@@ -96,7 +96,7 @@ Running tests works just as you would expect for individual MiniTest::Spec test
|
|
96
96
|
1. Push to the branch (`git push origin NNN-my-new-feature`). Remember that the first time pushing a branch to a remote requires an "unconditional" push (`git push -u origin NNN-my-new-feature`);
|
97
97
|
1. Create a new Pull Request. In the initial message, reference the open issue where your feature has been discussed; if no such issue exists (why?), then describe at some length the rationale for your new feature; your implementation strategy at a higher level than each individual commit message; anything future maintainers should be aware of; and so on. Modifications to existing code *must* have been discussed in an issue for PRs containing them to be accepted and merged;
|
98
98
|
1. Don't be discouraged if the PR generates further discussion leading to further refinement of your PR through additional commits. These should *generally* be discussed in comments on the relevant issue; discussion in the Gitter room (see below) may also be useful;
|
99
|
-
1. If you've comments, questions, or just want to talk through your ideas, come hang out in the project's [room on Gitter](https://gitter.im/rack-service_api_versioning). Ask away!
|
99
|
+
1. If you've comments, questions, or just want to talk through your ideas, come hang out in the project's [room on Gitter](https://gitter.im/jdickey/rack-service_api_versioning). Ask away!
|
100
100
|
|
101
101
|
## License
|
102
102
|
|
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: rack-service_api_versioning
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.1.
|
4
|
+
version: 0.1.1
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Jeff Dickey
|
8
8
|
autorequire:
|
9
9
|
bindir: exe
|
10
10
|
cert_chain: []
|
11
|
-
date: 2017-03-
|
11
|
+
date: 2017-03-27 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
name: prolog-dry_types
|