tk/Ocelot
1
0
Fork 0
mirror of https://github.com/nsnail/Ocelot.git synced 2025-06-19 17:28:16 +08:00
Code Issues Packages Projects Releases Wiki Activity

Feature/merge configuration files (#316)

Browse Source 
* #296 renamed configuration.json to ocelot.json in preparation

* removed things we dont need for tests

* another file we dont need

* removed some async we dont need

* refactoring to consolidate configuration code

* removed another pointless abstraction

* #296 started writing merge code

* #296 coming up with ideas for this config merging

* #296 still hacking this idea around

* #296 will now do a crappy merge on the configuration

* #296 change so tests pass on windows
This commit is contained in:
Tom Pallister
2018-04-17 22:06:41 +01:00
committed by GitHub
parent 3607c0867e
commit aa55fe34cb
84 changed files with 883 additions and 1050 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/introduction/notsupported.rst
View File

@ -7,7 +7,7 @@ Ocelot does not support...
* Fowarding a host header - The host header that you send to Ocelot will not be forwarded to the downstream service. Obviously this would break everything :(
* Swagger - I have looked multiple times at building swagger.json out of the Ocelot configuration.json but it doesnt fit into the vision
* Swagger - I have looked multiple times at building swagger.json out of the Ocelot ocelot.json but it doesnt fit into the vision
I have for Ocelot. If you would like to have Swagger in Ocelot then you must roll your own swagger.json and do the following in your
Startup.cs or Program.cs. The code sample below registers a piece of middleware that loads your hand rolled swagger.json and returns
it on /swagger/v1/swagger.json. It then registers the SwaggerUI middleware from Swashbuckle.AspNetCore
@ -28,8 +28,8 @@ it on /swagger/v1/swagger.json. It then registers the SwaggerUI middleware from
app.UseOcelot().Wait();
The main reasons why I don't think Swagger makes sense is we already hand roll our definition in configuration.json.
If we want people developing against Ocelot to be able to see what routes are available then either share the configuration.json
The main reasons why I don't think Swagger makes sense is we already hand roll our definition in ocelot.json.
If we want people developing against Ocelot to be able to see what routes are available then either share the ocelot.json
with them (This should be as easy as granting access to a repo etc) or use the Ocelot administration API so that they can query Ocelot for the configuration.
In addition to this many people will configure Ocelot to proxy all traffic like /products/{everything} to there product service
@ -40,4 +40,4 @@ package doesnt reload swagger.json if it changes during runtime. Ocelot's config
information would not match. Unless I rolled my own Swagger implementation.
If the user wants something to easily test against the Ocelot API then I suggest using Postman as a simple way to do this. It might
even be possible to write something that maps configuration.json to the postman json spec. However I don't intend to do this.
even be possible to write something that maps ocelot.json to the postman json spec. However I don't intend to do this.