8000 Update README.md by jonhkr · Pull Request #1 · augusto/restVersioning · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Update README.md #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update README.md #1

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,11 +1,11 @@
#Spring REST versioning extension (POC)
# Spring REST versioning extension (POC)


This is a Spring extension that allows routing to different methods depending on the version of the resource that is
requested. This code is based on the suggestions from a Stack Overflow question I asked - [How to manage REST API versioning with
spring?](http://stackoverflow.com/questions/20198275/how-to-manage-rest-api-versioning-with-spring ).

##Approaches to manage versions
## Approaches to manage versions
There are 2 main approaches to manage versions. One is to make the version explicit as part of the URL
(e.g. http://host.com/1.1/resource), but this goes against the purist view that a resource identifier, should be the
same regardless of the representation. The more *correct* approach is to use the Accept header to differentiate the
Expand Down Expand Up @@ -52,15 +52,15 @@ allows to to extend the default `RequestMappingHandlerMapping` in order to add a
`VersionedResourceRequestCondition` is responsible for figuring out if a controller method is a candidate to be invoked.


##Drawbacks of this implementation
## Drawbacks of this implementation
1. Given that we need a custom `RequestMappingHandlerMapping`, instantiating it is non-trivial (see the
`WebConfiguration` class) and there's a danger that this class will change in a follow up version of spring and might
cause unexpected behaviour.
2. This implementation doesn't check for a version upper boundary in the `@VersionedResource` and also routes higher,
non-existent versions to methods without a version upper boundary
(see `TestControllerTest.shouldReturnUnboundedVersionForCallToVersion32`).

##When is this approach a bad idea?
## When is this approach a bad idea?
I think using versions on the URLs for public APIs is a better approach as the users might not be familiar with HTTP
(as an example Twitter and Facebook put the version on the URL). In these cases, making the API as simple as possible
to use is quite important.
to use is quite important.
0