https://github.com/i-e-b/webjony
An API version control and hosting solution for ASP.Net
https://github.com/i-e-b/webjony
api-wrapper asp-net iis old server version-manager working
Last synced: over 1 year ago
JSON representation
An API version control and hosting solution for ASP.Net
- Host: GitHub
- URL: https://github.com/i-e-b/webjony
- Owner: i-e-b
- Created: 2018-07-26T13:21:48.000Z (almost 8 years ago)
- Default Branch: master
- Last Pushed: 2018-08-13T11:55:02.000Z (almost 8 years ago)
- Last Synced: 2025-01-27T12:11:11.815Z (over 1 year ago)
- Topics: api-wrapper, asp-net, iis, old, server, version-manager, working
- Language: C#
- Homepage:
- Size: 189 KB
- Stars: 0
- Watchers: 2
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: Readme.txt
Awesome Lists containing this project
README
Wrapper Test
============
Example of a web app that loads various other MVC Web API sites, and provides various security, logging and API versioning tools.
Features:
---------
* [x] Global error handling
* [x] AAD security unwrapping
* [x] watcher/loader
* [x] Real routing to services
* [x] Expose SwaggerUI calls
* [x] Signed-binary upload tool, require signed binaries on host. (note: the cert used is found by fixed name: "WrapperSigning.pfx.cer")
* [x] Handle differing versions of `System.Web.Http` in different versions of hosted site
* [x] Ensure that redirects work (change `localhost` bounces up to proxy parent)
* [x] Edit target site version to set , ,
* [x] Collect security and version header in Swagger
* [x] Keep old versions running until new version is warm (plus pre-warm with a call to '/health')
* [x] Delete failed updates
* [x] Root-level health check (call to all versions' /health endpoint and display)
* [x] Error/failure statistics (parent gathers failures and provides them on the health endpoint)
* [x] Optional force HTTPS upgrade
* [x] Ensure upload tool works if given a http endpoint and the target auto-upgrades
* [x] Rapid call test in JwtEndpointCaller (multithread calls)
* [x] Reject known dll names from the file system scan (speed up start-up)
* [x] Remove hard-coding, push account keys to a non-committed file
* [x] Simple hosting on IIS (Custom version of RawIsapi project)
* [x] Some graphs -- one that shows % proportion of versions over time, and the other where you pick a version and it shows % errors over time
TODO:
-----
Next up:
* [ ] Analytics integration point, including an Azure App Insights example
Approximate priority order:
* [ ] Centralised package data store (for Azure hosting)
* [ ] Status API (add to management tool, and retire the test page?)
* [ ] Ability to change logging level on the fly
* [ ] Stats API (including graph output urls)
* [ ] Removal of specific versions? (delete by major & minor)
* [ ] New version feed-in mode? (newer minor versions get progressively more traffic?)
* [ ] Automatic A/B testing (50% feed, watch error rates)
* [ ] Version limit / retiring (limit on how many major versions can be active at once, with oldest being inaccessible)
* [ ] Options for CORS header support
* [ ] Gasconade version page
* [ ] Automatic result compression
* [ ] Sample Service Fabric deployment
Potential features:
-------------------
* [ ] Ability to point different versions at different web.config transforms (i.e. latest version can be set to test db until stabilised)
* [ ] Ability to host function dlls (not using Huygens?)
* [ ] Static 'oops' result for 500-class errors in hosted site?
* [ ] Delete uploads that are out-of-date (if the version table rejects them)
* [ ] Optional service bus trace listener, or configurable listener injection
* [ ] Optional default version (that can we switched while live) -- for websites.
* [ ] Per-client rate limiting (rate limit how much any single IP can push/pull)
* [ ] White list upload IPs
Notes:
------
Request versioning is done with a header, with a major version only:
```
GET /user/1 HTTP/1.1
Host: myapplication.com
Accept: application/json
Version: 1
```
Using AAD security requires supplying your own `security.json` file. An example is provided.
Application versioning is done with a combination of build number and API major version.
So like `[ApplicationSetupPoint(Major:3)]` and a build number of `2018.2.10.1`, the entire build number would be the minor.
You would see it described in the system as `3-2018.2.10.1`
Only the latest of each major version is kept, any earlier ones are rejected.