Proxy for easier frontend development

[Florian-Schoenherr]

Took a while for me to find out how to do this. Wasn't even that hard. Also, generally the api is on a "special" route, so I changed this around. Still works the same way (also, proxying worked this way). I updated links accordingly. Location headers still use the url without "/api" infront, but are also unused, I think? Should I update them? They are (generally) used for redirecting, right?

[Florian-Schoenherr]

@VaughnVernon Before, it was /organizations, now it is /api/organizations, so this is not really different from before. If people then depend on schematas API, we should "deprecate" the old version and announce the change. old: /api/organizations new: /api/v2/organizations after maybe 6 months catch-up time: ~/api/v2/organizations~ /api/organizations <-this is now v2 If people somehow still missed the changes while also updating schemata (I hope that would be rare), they can file an issue. I just thought this up, what do you think?

Resource versioning also sounds nice, could be a cool addition to VLINGO/HTTP.

[VaughnVernon]

@Florian-Schoenherr I like the idea of using content negotiation rather than resource path versions. Let's try that first. We can start here: Content-Type: application/vnd.vlingo.schemata.v1+json

Regarding deprecating URIs and then eventually renaming versions, as you said:

old: /api/organizations
new: /api/v2/organizations
after maybe 6 months catch-up time: /api/v2/organizations /api/organizations <-this is now v2

I don't think that would work well unless the app is completely HATEOAS. The idea is that once you go from v1 to v2 you never go back. You can deprecate v1 and remove it later, but you never rename v2 to v1.

Did I misunderstand your idea? If so, do you have a reference that supports it?

[Florian-Schoenherr]

I think I forgot that people who actually update to api/v2/ would need to change back to api/.. So it would only work if we did for example: /api/.. <- always newest version /api/v1/.. <- v1 /api/v2/.. <- v2 etc. But I also like Resource versioning better, will put it on the backlog.