Jersey: Is there a clean way to specify allowed URL extensions?
3
I'm using Jersey 1.17.1 and on every URL I've created I want to allow people to put ".json" at the end or not. Here's an example of what I've done:
@GET
@Path("basepath{extension: (\.json)?}")
public String foobar() {
...
}
Eventually I'm going to let them choose between nothing, ".json" or ".xml" and I'm concerned about my DRY violation here. I'll have to change every @Path to this instead:
@GET
@Path("basepath{extension: (\.json|\.xml)?}")
public String foobar() {
...
}
Is there a better way to do this that lets my path value be more reusable? Although I can't use Jersey 2.0, I'd be interested to know if it can solve this problem.
java rest jersey jersey-1.0
asked Sep 17 '13 at 22:41
Daniel KaplanDaniel Kaplan
36.8k24145221
add a comment |
3
I'm using Jersey 1.17.1 and on every URL I've created I want to allow people to put ".json" at the end or not. Here's an example of what I've done:
@GET
@Path("basepath{extension: (\.json)?}")
public String foobar() {
...
}
Eventually I'm going to let them choose between nothing, ".json" or ".xml" and I'm concerned about my DRY violation here. I'll have to change every @Path to this instead:
@GET
@Path("basepath{extension: (\.json|\.xml)?}")
public String foobar() {
...
}
Is there a better way to do this that lets my path value be more reusable? Although I can't use Jersey 2.0, I'd be interested to know if it can solve this problem.
java rest jersey jersey-1.0
asked Sep 17 '13 at 22:41
Daniel KaplanDaniel Kaplan
36.8k24145221
add a comment |
3
3
3
I'm using Jersey 1.17.1 and on every URL I've created I want to allow people to put ".json" at the end or not. Here's an example of what I've done:
@GET
@Path("basepath{extension: (\.json)?}")
public String foobar() {
...
}
Eventually I'm going to let them choose between nothing, ".json" or ".xml" and I'm concerned about my DRY violation here. I'll have to change every @Path to this instead:
@GET
@Path("basepath{extension: (\.json|\.xml)?}")
public String foobar() {
...
}
Is there a better way to do this that lets my path value be more reusable? Although I can't use Jersey 2.0, I'd be interested to know if it can solve this problem.
java rest jersey jersey-1.0
asked Sep 17 '13 at 22:41
Daniel KaplanDaniel Kaplan
36.8k24145221
I'm using Jersey 1.17.1 and on every URL I've created I want to allow people to put ".json" at the end or not. Here's an example of what I've done:
@GET
@Path("basepath{extension: (\.json)?}")
public String foobar() {
...
}
Eventually I'm going to let them choose between nothing, ".json" or ".xml" and I'm concerned about my DRY violation here. I'll have to change every @Path to this instead:
@GET
@Path("basepath{extension: (\.json|\.xml)?}")
public String foobar() {
...
}
Is there a better way to do this that lets my path value be more reusable? Although I can't use Jersey 2.0, I'd be interested to know if it can solve this problem.
java rest jersey jersey-1.0
java rest jersey jersey-1.0
asked Sep 17 '13 at 22:41
Daniel KaplanDaniel Kaplan
36.8k24145221
asked Sep 17 '13 at 22:41
Daniel KaplanDaniel Kaplan
36.8k24145221
asked Sep 17 '13 at 22:41
Daniel KaplanDaniel Kaplan
36.8k24145221
asked Sep 17 '13 at 22:41
Daniel KaplanDaniel Kaplan
36.8k24145221
asked Sep 17 '13 at 22:41
Daniel KaplanDaniel Kaplan
36.8k24145221
36.8k24145221
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
5
One way to do this is to subclass PackagesResourceConfig and inform Jersey which extensions should map to which media types. For instance:
public class ExampleResourceConfig extends PackagesResourceConfig {
@Override
public Map<String, MediaType> getMediaTypeMappings() {
Map<String, MediaType> map = new HashMap<>();
map.put("xml", MediaType.APPLICATION_XML_TYPE);
map.put("json", MediaType.APPLICATION_JSON_TYPE);
return map;
}
}
and then your actual REST service might look like:
@GET
@Path("basepath")
@Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
public Response foobar() {
...
}
Jersey will select the appropriate media type based on the url extension. Note that Response is returned instead of String. I'm not sure how you're building your response and what your requirements are but Jersey can handle converting your Java beans into either XML or JSON (or even JSONP) without a problem.
answered Sep 17 '13 at 23:59
conditcondit
9,00023157
That's pretty cool. What if I threw another requirement in there: I want one special path to be for PDF. Can that be accomplished by avoiding it in thegetMediaTypeMappingsand explicitly setting it as a@Produceson the resource code?
– Daniel Kaplan
Sep 18 '13 at 0:24
1
Sure - you've got some options there. I would still add PDF to your media type mappings. You could write a separate method with the same@Paththat just@ProducesPDF. You could add PDF to the@Producesof your existing method, detect if PDF was requested by the client and modify the response accordingly. Or, if your response beans are conducive to it, you could implement a MessageBodyWriter that@ProducesPDF. Then you would just add@ProducesPDF to your existing foobar method and you're done.
– condit
Sep 18 '13 at 14:28
This option also handles requests with no URL extension: Jersey will serve the firstMediaTypeannotation unless the client adds anAcceptheader, in which case Jersey will serve that media type. This way you can comply with accept headers and have the convenience of changing the return type by changing the URL extension in your browser.
– condit
Sep 18 '13 at 16:44
1
Note that in Jersey 2.x, you can just setinit-paramjersey.config.server.mediaTypeMappings in web.xml, with a value containing a list of name:value extension pairs:<init-param> <param-name>jersey.config.server.mediaTypeMappings</param-name> <param-value>txt : text/plain, xml : application/xml, json : application/json</param-value> </init-param>
– Buzz Killington
Oct 3 '14 at 16:01
@condit I am doing a similar thing in my application and am facing an issue. When i make a GET call with .xml as extension, I am getting the expected response where as, when i am trying with .json, it is returning an empty response with 200. What could be the issue?
– doctore
Sep 6 '16 at 15:09
add a comment |
0
In the REST API implementation , the resource representation can be either xml or json or etc. This is not a good way of restful implementation if you specify the types as the extensions of the URL. The correct way is to use HTTP ACCEPT header
like Accept: application/json or
Accept: application/xml
Refer : http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
answered Sep 18 '13 at 7:05
Vineet SinglaVineet Singla
1,1321425
1
I think if you're going to be pedantic, you're right. But the benefit of being able to test this in the browser is totally worth it in my opinion.
– Daniel Kaplan
Sep 18 '13 at 7:25
Actually, please take this opportunity to enlighten me: What bad things will happen if I violate this?
– Daniel Kaplan
Sep 18 '13 at 16:22
A resource has its representation and a unique URL. but in this scenario the same resource will be represented by different URLs. So from the client perspective it has 2-3 different URls represtenting the same resource and could create confusion. Consider u have 3 formats xml,json,html , so u would have to provide 3 urls. And as far as the representation format is considered we can provide this in HTTP header, and URL remains the same.
– Vineet Singla
Sep 19 '13 at 4:59
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f18861071%2fjersey-is-there-a-clean-way-to-specify-allowed-url-extensions%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
5
One way to do this is to subclass PackagesResourceConfig and inform Jersey which extensions should map to which media types. For instance:
public class ExampleResourceConfig extends PackagesResourceConfig {
@Override
public Map<String, MediaType> getMediaTypeMappings() {
Map<String, MediaType> map = new HashMap<>();
map.put("xml", MediaType.APPLICATION_XML_TYPE);
map.put("json", MediaType.APPLICATION_JSON_TYPE);
return map;
}
}
and then your actual REST service might look like:
@GET
@Path("basepath")
@Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
public Response foobar() {
...
}
Jersey will select the appropriate media type based on the url extension. Note that Response is returned instead of String. I'm not sure how you're building your response and what your requirements are but Jersey can handle converting your Java beans into either XML or JSON (or even JSONP) without a problem.
answered Sep 17 '13 at 23:59
conditcondit
9,00023157
That's pretty cool. What if I threw another requirement in there: I want one special path to be for PDF. Can that be accomplished by avoiding it in thegetMediaTypeMappingsand explicitly setting it as a@Produceson the resource code?
– Daniel Kaplan
Sep 18 '13 at 0:24
1
Sure - you've got some options there. I would still add PDF to your media type mappings. You could write a separate method with the same@Paththat just@ProducesPDF. You could add PDF to the@Producesof your existing method, detect if PDF was requested by the client and modify the response accordingly. Or, if your response beans are conducive to it, you could implement a MessageBodyWriter that@ProducesPDF. Then you would just add@ProducesPDF to your existing foobar method and you're done.
– condit
Sep 18 '13 at 14:28
This option also handles requests with no URL extension: Jersey will serve the firstMediaTypeannotation unless the client adds anAcceptheader, in which case Jersey will serve that media type. This way you can comply with accept headers and have the convenience of changing the return type by changing the URL extension in your browser.
– condit
Sep 18 '13 at 16:44
1
Note that in Jersey 2.x, you can just setinit-paramjersey.config.server.mediaTypeMappings in web.xml, with a value containing a list of name:value extension pairs:<init-param> <param-name>jersey.config.server.mediaTypeMappings</param-name> <param-value>txt : text/plain, xml : application/xml, json : application/json</param-value> </init-param>
– Buzz Killington
Oct 3 '14 at 16:01
@condit I am doing a similar thing in my application and am facing an issue. When i make a GET call with .xml as extension, I am getting the expected response where as, when i am trying with .json, it is returning an empty response with 200. What could be the issue?
– doctore
Sep 6 '16 at 15:09
add a comment |
5
One way to do this is to subclass PackagesResourceConfig and inform Jersey which extensions should map to which media types. For instance:
public class ExampleResourceConfig extends PackagesResourceConfig {
@Override
public Map<String, MediaType> getMediaTypeMappings() {
Map<String, MediaType> map = new HashMap<>();
map.put("xml", MediaType.APPLICATION_XML_TYPE);
map.put("json", MediaType.APPLICATION_JSON_TYPE);
return map;
}
}
and then your actual REST service might look like:
@GET
@Path("basepath")
@Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
public Response foobar() {
...
}
Jersey will select the appropriate media type based on the url extension. Note that Response is returned instead of String. I'm not sure how you're building your response and what your requirements are but Jersey can handle converting your Java beans into either XML or JSON (or even JSONP) without a problem.
answered Sep 17 '13 at 23:59
conditcondit
9,00023157
That's pretty cool. What if I threw another requirement in there: I want one special path to be for PDF. Can that be accomplished by avoiding it in thegetMediaTypeMappingsand explicitly setting it as a@Produceson the resource code?
– Daniel Kaplan
Sep 18 '13 at 0:24
1
Sure - you've got some options there. I would still add PDF to your media type mappings. You could write a separate method with the same@Paththat just@ProducesPDF. You could add PDF to the@Producesof your existing method, detect if PDF was requested by the client and modify the response accordingly. Or, if your response beans are conducive to it, you could implement a MessageBodyWriter that@ProducesPDF. Then you would just add@ProducesPDF to your existing foobar method and you're done.
– condit
Sep 18 '13 at 14:28
This option also handles requests with no URL extension: Jersey will serve the firstMediaTypeannotation unless the client adds anAcceptheader, in which case Jersey will serve that media type. This way you can comply with accept headers and have the convenience of changing the return type by changing the URL extension in your browser.
– condit
Sep 18 '13 at 16:44
1
Note that in Jersey 2.x, you can just setinit-paramjersey.config.server.mediaTypeMappings in web.xml, with a value containing a list of name:value extension pairs:<init-param> <param-name>jersey.config.server.mediaTypeMappings</param-name> <param-value>txt : text/plain, xml : application/xml, json : application/json</param-value> </init-param>
– Buzz Killington
Oct 3 '14 at 16:01
@condit I am doing a similar thing in my application and am facing an issue. When i make a GET call with .xml as extension, I am getting the expected response where as, when i am trying with .json, it is returning an empty response with 200. What could be the issue?
– doctore
Sep 6 '16 at 15:09
add a comment |
5
5
5
One way to do this is to subclass PackagesResourceConfig and inform Jersey which extensions should map to which media types. For instance:
public class ExampleResourceConfig extends PackagesResourceConfig {
@Override
public Map<String, MediaType> getMediaTypeMappings() {
Map<String, MediaType> map = new HashMap<>();
map.put("xml", MediaType.APPLICATION_XML_TYPE);
map.put("json", MediaType.APPLICATION_JSON_TYPE);
return map;
}
}
and then your actual REST service might look like:
@GET
@Path("basepath")
@Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
public Response foobar() {
...
}
Jersey will select the appropriate media type based on the url extension. Note that Response is returned instead of String. I'm not sure how you're building your response and what your requirements are but Jersey can handle converting your Java beans into either XML or JSON (or even JSONP) without a problem.
answered Sep 17 '13 at 23:59
conditcondit
9,00023157
One way to do this is to subclass PackagesResourceConfig and inform Jersey which extensions should map to which media types. For instance:
public class ExampleResourceConfig extends PackagesResourceConfig {
@Override
public Map<String, MediaType> getMediaTypeMappings() {
Map<String, MediaType> map = new HashMap<>();
map.put("xml", MediaType.APPLICATION_XML_TYPE);
map.put("json", MediaType.APPLICATION_JSON_TYPE);
return map;
}
}
and then your actual REST service might look like:
@GET
@Path("basepath")
@Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
public Response foobar() {
...
}
Jersey will select the appropriate media type based on the url extension. Note that Response is returned instead of String. I'm not sure how you're building your response and what your requirements are but Jersey can handle converting your Java beans into either XML or JSON (or even JSONP) without a problem.
answered Sep 17 '13 at 23:59
conditcondit
9,00023157
edited Oct 3 '14 at 16:05
answered Sep 17 '13 at 23:59
conditcondit
9,00023157
answered Sep 17 '13 at 23:59
conditcondit
9,00023157
answered Sep 17 '13 at 23:59
conditcondit
9,00023157
9,00023157
That's pretty cool. What if I threw another requirement in there: I want one special path to be for PDF. Can that be accomplished by avoiding it in thegetMediaTypeMappingsand explicitly setting it as a@Produceson the resource code?
– Daniel Kaplan
Sep 18 '13 at 0:24
1
Sure - you've got some options there. I would still add PDF to your media type mappings. You could write a separate method with the same@Paththat just@ProducesPDF. You could add PDF to the@Producesof your existing method, detect if PDF was requested by the client and modify the response accordingly. Or, if your response beans are conducive to it, you could implement a MessageBodyWriter that@ProducesPDF. Then you would just add@ProducesPDF to your existing foobar method and you're done.
– condit
Sep 18 '13 at 14:28
This option also handles requests with no URL extension: Jersey will serve the firstMediaTypeannotation unless the client adds anAcceptheader, in which case Jersey will serve that media type. This way you can comply with accept headers and have the convenience of changing the return type by changing the URL extension in your browser.
– condit
Sep 18 '13 at 16:44
1
Note that in Jersey 2.x, you can just setinit-paramjersey.config.server.mediaTypeMappings in web.xml, with a value containing a list of name:value extension pairs:<init-param> <param-name>jersey.config.server.mediaTypeMappings</param-name> <param-value>txt : text/plain, xml : application/xml, json : application/json</param-value> </init-param>
– Buzz Killington
Oct 3 '14 at 16:01
@condit I am doing a similar thing in my application and am facing an issue. When i make a GET call with .xml as extension, I am getting the expected response where as, when i am trying with .json, it is returning an empty response with 200. What could be the issue?
– doctore
Sep 6 '16 at 15:09
add a comment |
That's pretty cool. What if I threw another requirement in there: I want one special path to be for PDF. Can that be accomplished by avoiding it in thegetMediaTypeMappingsand explicitly setting it as a@Produceson the resource code?
– Daniel Kaplan
Sep 18 '13 at 0:24
1
Sure - you've got some options there. I would still add PDF to your media type mappings. You could write a separate method with the same@Paththat just@ProducesPDF. You could add PDF to the@Producesof your existing method, detect if PDF was requested by the client and modify the response accordingly. Or, if your response beans are conducive to it, you could implement a MessageBodyWriter that@ProducesPDF. Then you would just add@ProducesPDF to your existing foobar method and you're done.
– condit
Sep 18 '13 at 14:28
This option also handles requests with no URL extension: Jersey will serve the firstMediaTypeannotation unless the client adds anAcceptheader, in which case Jersey will serve that media type. This way you can comply with accept headers and have the convenience of changing the return type by changing the URL extension in your browser.
– condit
Sep 18 '13 at 16:44
1
Note that in Jersey 2.x, you can just setinit-paramjersey.config.server.mediaTypeMappings in web.xml, with a value containing a list of name:value extension pairs:<init-param> <param-name>jersey.config.server.mediaTypeMappings</param-name> <param-value>txt : text/plain, xml : application/xml, json : application/json</param-value> </init-param>
– Buzz Killington
Oct 3 '14 at 16:01
@condit I am doing a similar thing in my application and am facing an issue. When i make a GET call with .xml as extension, I am getting the expected response where as, when i am trying with .json, it is returning an empty response with 200. What could be the issue?
– doctore
Sep 6 '16 at 15:09
That's pretty cool. What if I threw another requirement in there: I want one special path to be for PDF. Can that be accomplished by avoiding it in the
getMediaTypeMappings and explicitly setting it as a @Produces on the resource code?– Daniel Kaplan
Sep 18 '13 at 0:24
That's pretty cool. What if I threw another requirement in there: I want one special path to be for PDF. Can that be accomplished by avoiding it in the
getMediaTypeMappings and explicitly setting it as a @Produces on the resource code?– Daniel Kaplan
Sep 18 '13 at 0:24
1
1
Sure - you've got some options there. I would still add PDF to your media type mappings. You could write a separate method with the same
@Path that just @Produces PDF. You could add PDF to the @Produces of your existing method, detect if PDF was requested by the client and modify the response accordingly. Or, if your response beans are conducive to it, you could implement a MessageBodyWriter that @Produces PDF. Then you would just add @Produces PDF to your existing foobar method and you're done.– condit
Sep 18 '13 at 14:28
Sure - you've got some options there. I would still add PDF to your media type mappings. You could write a separate method with the same
@Path that just @Produces PDF. You could add PDF to the @Produces of your existing method, detect if PDF was requested by the client and modify the response accordingly. Or, if your response beans are conducive to it, you could implement a MessageBodyWriter that @Produces PDF. Then you would just add @Produces PDF to your existing foobar method and you're done.– condit
Sep 18 '13 at 14:28
This option also handles requests with no URL extension: Jersey will serve the first
MediaType annotation unless the client adds an Accept header, in which case Jersey will serve that media type. This way you can comply with accept headers and have the convenience of changing the return type by changing the URL extension in your browser.– condit
Sep 18 '13 at 16:44
This option also handles requests with no URL extension: Jersey will serve the first
MediaType annotation unless the client adds an Accept header, in which case Jersey will serve that media type. This way you can comply with accept headers and have the convenience of changing the return type by changing the URL extension in your browser.– condit
Sep 18 '13 at 16:44
1
1
Note that in Jersey 2.x, you can just set
init-param jersey.config.server.mediaTypeMappings in web.xml, with a value containing a list of name:value extension pairs: <init-param> <param-name>jersey.config.server.mediaTypeMappings</param-name> <param-value>txt : text/plain, xml : application/xml, json : application/json</param-value> </init-param>– Buzz Killington
Oct 3 '14 at 16:01
Note that in Jersey 2.x, you can just set
init-param jersey.config.server.mediaTypeMappings in web.xml, with a value containing a list of name:value extension pairs: <init-param> <param-name>jersey.config.server.mediaTypeMappings</param-name> <param-value>txt : text/plain, xml : application/xml, json : application/json</param-value> </init-param>– Buzz Killington
Oct 3 '14 at 16:01
@condit I am doing a similar thing in my application and am facing an issue. When i make a GET call with .xml as extension, I am getting the expected response where as, when i am trying with .json, it is returning an empty response with 200. What could be the issue?
– doctore
Sep 6 '16 at 15:09
@condit I am doing a similar thing in my application and am facing an issue. When i make a GET call with .xml as extension, I am getting the expected response where as, when i am trying with .json, it is returning an empty response with 200. What could be the issue?
– doctore
Sep 6 '16 at 15:09
add a comment |
0
In the REST API implementation , the resource representation can be either xml or json or etc. This is not a good way of restful implementation if you specify the types as the extensions of the URL. The correct way is to use HTTP ACCEPT header
like Accept: application/json or
Accept: application/xml
Refer : http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
answered Sep 18 '13 at 7:05
Vineet SinglaVineet Singla
1,1321425
1
I think if you're going to be pedantic, you're right. But the benefit of being able to test this in the browser is totally worth it in my opinion.
– Daniel Kaplan
Sep 18 '13 at 7:25
Actually, please take this opportunity to enlighten me: What bad things will happen if I violate this?
– Daniel Kaplan
Sep 18 '13 at 16:22
A resource has its representation and a unique URL. but in this scenario the same resource will be represented by different URLs. So from the client perspective it has 2-3 different URls represtenting the same resource and could create confusion. Consider u have 3 formats xml,json,html , so u would have to provide 3 urls. And as far as the representation format is considered we can provide this in HTTP header, and URL remains the same.
– Vineet Singla
Sep 19 '13 at 4:59
add a comment |
0
In the REST API implementation , the resource representation can be either xml or json or etc. This is not a good way of restful implementation if you specify the types as the extensions of the URL. The correct way is to use HTTP ACCEPT header
like Accept: application/json or
Accept: application/xml
Refer : http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
answered Sep 18 '13 at 7:05
Vineet SinglaVineet Singla
1,1321425
1
I think if you're going to be pedantic, you're right. But the benefit of being able to test this in the browser is totally worth it in my opinion.
– Daniel Kaplan
Sep 18 '13 at 7:25
Actually, please take this opportunity to enlighten me: What bad things will happen if I violate this?
– Daniel Kaplan
Sep 18 '13 at 16:22
A resource has its representation and a unique URL. but in this scenario the same resource will be represented by different URLs. So from the client perspective it has 2-3 different URls represtenting the same resource and could create confusion. Consider u have 3 formats xml,json,html , so u would have to provide 3 urls. And as far as the representation format is considered we can provide this in HTTP header, and URL remains the same.
– Vineet Singla
Sep 19 '13 at 4:59
add a comment |
0
0
0
In the REST API implementation , the resource representation can be either xml or json or etc. This is not a good way of restful implementation if you specify the types as the extensions of the URL. The correct way is to use HTTP ACCEPT header
like Accept: application/json or
Accept: application/xml
Refer : http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
answered Sep 18 '13 at 7:05
Vineet SinglaVineet Singla
1,1321425
In the REST API implementation , the resource representation can be either xml or json or etc. This is not a good way of restful implementation if you specify the types as the extensions of the URL. The correct way is to use HTTP ACCEPT header
like Accept: application/json or
Accept: application/xml
Refer : http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
answered Sep 18 '13 at 7:05
Vineet SinglaVineet Singla
1,1321425
answered Sep 18 '13 at 7:05
Vineet SinglaVineet Singla
1,1321425
answered Sep 18 '13 at 7:05
Vineet SinglaVineet Singla
1,1321425
answered Sep 18 '13 at 7:05
Vineet SinglaVineet Singla
1,1321425
1,1321425
1
I think if you're going to be pedantic, you're right. But the benefit of being able to test this in the browser is totally worth it in my opinion.
– Daniel Kaplan
Sep 18 '13 at 7:25
Actually, please take this opportunity to enlighten me: What bad things will happen if I violate this?
– Daniel Kaplan
Sep 18 '13 at 16:22
A resource has its representation and a unique URL. but in this scenario the same resource will be represented by different URLs. So from the client perspective it has 2-3 different URls represtenting the same resource and could create confusion. Consider u have 3 formats xml,json,html , so u would have to provide 3 urls. And as far as the representation format is considered we can provide this in HTTP header, and URL remains the same.
– Vineet Singla
Sep 19 '13 at 4:59
add a comment |
1
I think if you're going to be pedantic, you're right. But the benefit of being able to test this in the browser is totally worth it in my opinion.
– Daniel Kaplan
Sep 18 '13 at 7:25
Actually, please take this opportunity to enlighten me: What bad things will happen if I violate this?
– Daniel Kaplan
Sep 18 '13 at 16:22
A resource has its representation and a unique URL. but in this scenario the same resource will be represented by different URLs. So from the client perspective it has 2-3 different URls represtenting the same resource and could create confusion. Consider u have 3 formats xml,json,html , so u would have to provide 3 urls. And as far as the representation format is considered we can provide this in HTTP header, and URL remains the same.
– Vineet Singla
Sep 19 '13 at 4:59
1
1
I think if you're going to be pedantic, you're right. But the benefit of being able to test this in the browser is totally worth it in my opinion.
– Daniel Kaplan
Sep 18 '13 at 7:25
I think if you're going to be pedantic, you're right. But the benefit of being able to test this in the browser is totally worth it in my opinion.
– Daniel Kaplan
Sep 18 '13 at 7:25
Actually, please take this opportunity to enlighten me: What bad things will happen if I violate this?
– Daniel Kaplan
Sep 18 '13 at 16:22
Actually, please take this opportunity to enlighten me: What bad things will happen if I violate this?
– Daniel Kaplan
Sep 18 '13 at 16:22
A resource has its representation and a unique URL. but in this scenario the same resource will be represented by different URLs. So from the client perspective it has 2-3 different URls represtenting the same resource and could create confusion. Consider u have 3 formats xml,json,html , so u would have to provide 3 urls. And as far as the representation format is considered we can provide this in HTTP header, and URL remains the same.
– Vineet Singla
Sep 19 '13 at 4:59
A resource has its representation and a unique URL. but in this scenario the same resource will be represented by different URLs. So from the client perspective it has 2-3 different URls represtenting the same resource and could create confusion. Consider u have 3 formats xml,json,html , so u would have to provide 3 urls. And as far as the representation format is considered we can provide this in HTTP header, and URL remains the same.
– Vineet Singla
Sep 19 '13 at 4:59
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f18861071%2fjersey-is-there-a-clean-way-to-specify-allowed-url-extensions%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
