Data collection best practice using REST APis
Consider I have a data collection API that is using a resource as follows,
{
user: {
id:"c5667fb4-2348-4ccc-afc4-2309077a09ad"
documents :[
{
type:"PASSPORT",
value:"1234"
issue_date:"11/11/2011"
},
{
type:"DRIVING_LICENSE",
value:"5678"
issue_date:"11/11/2001"
}
]
}
}
For a given user that a client is interested in, I need to be able to evaluate and respond through my API and ask for any of the missing documents - Like for example a user might have provided only PASSPORT on creation time so I need to now ask only for DRIVING_LICENSE.
For this I was thinking of a controller endpoint(like an "evaluate") to be able to send a response that indicates what data the user is missing.
the client can invoke POST: /evaluate/c5667fb4-2348-4ccc-afc4-2309077a09ad
and now say that this user is missing DRIVING_LICENSE the response should indicate what is missing like follows - I am using json path to define what I am looking for
{
required_data:[
{
path:"user.documents[?(@.type=="DRIVING_LICENSE")].type"
}
]
}
Is this a reasonable way to express this requirement or is there a more correct way to do this?
rest jsonpath
add a comment |
Consider I have a data collection API that is using a resource as follows,
{
user: {
id:"c5667fb4-2348-4ccc-afc4-2309077a09ad"
documents :[
{
type:"PASSPORT",
value:"1234"
issue_date:"11/11/2011"
},
{
type:"DRIVING_LICENSE",
value:"5678"
issue_date:"11/11/2001"
}
]
}
}
For a given user that a client is interested in, I need to be able to evaluate and respond through my API and ask for any of the missing documents - Like for example a user might have provided only PASSPORT on creation time so I need to now ask only for DRIVING_LICENSE.
For this I was thinking of a controller endpoint(like an "evaluate") to be able to send a response that indicates what data the user is missing.
the client can invoke POST: /evaluate/c5667fb4-2348-4ccc-afc4-2309077a09ad
and now say that this user is missing DRIVING_LICENSE the response should indicate what is missing like follows - I am using json path to define what I am looking for
{
required_data:[
{
path:"user.documents[?(@.type=="DRIVING_LICENSE")].type"
}
]
}
Is this a reasonable way to express this requirement or is there a more correct way to do this?
rest jsonpath
I feel that the general title of the question is too broad. Are both passpord AND driving license necessary in your use case? If yes, should partial uploads of such documents be supported? If so, you need a way to attach the document to the initial request. There are a couple of ways to achive this. In HTML i.e. you return a form to tell the client what information is needed/missing. By using custom, over-generic (plain JSON) media-types a client needs out-of-band information on processing such a request, which is a bit against RESTs intention TBH.
– Roman Vottner
Nov 21 '18 at 13:52
Apologies if the title is not specific enough. The use case here is something like the user is trying to apply for a new product which requires a some more information to be collected as generally(for us) the information provided at onboarding(user creation) is pretty minimal. To give some more context, this is for a mid tier component that houses what data is needed for a specific product and hence I was alluding towards how to do this via APIs.
– user3738616
Nov 21 '18 at 15:44
In general the best advice in terms of REST architecture given is to design the interaction flow as if you deal with a browser-based service that ships HTML pages. You might replace HTML with JSON, though the important segments like forms and such should be present in this representation format as well. The syntax used as well as the semantics of elements should be defined as closely as possible to avoid confusion. Ideally you'd also register such a media type with IANA
– Roman Vottner
Nov 21 '18 at 17:10
add a comment |
Consider I have a data collection API that is using a resource as follows,
{
user: {
id:"c5667fb4-2348-4ccc-afc4-2309077a09ad"
documents :[
{
type:"PASSPORT",
value:"1234"
issue_date:"11/11/2011"
},
{
type:"DRIVING_LICENSE",
value:"5678"
issue_date:"11/11/2001"
}
]
}
}
For a given user that a client is interested in, I need to be able to evaluate and respond through my API and ask for any of the missing documents - Like for example a user might have provided only PASSPORT on creation time so I need to now ask only for DRIVING_LICENSE.
For this I was thinking of a controller endpoint(like an "evaluate") to be able to send a response that indicates what data the user is missing.
the client can invoke POST: /evaluate/c5667fb4-2348-4ccc-afc4-2309077a09ad
and now say that this user is missing DRIVING_LICENSE the response should indicate what is missing like follows - I am using json path to define what I am looking for
{
required_data:[
{
path:"user.documents[?(@.type=="DRIVING_LICENSE")].type"
}
]
}
Is this a reasonable way to express this requirement or is there a more correct way to do this?
rest jsonpath
Consider I have a data collection API that is using a resource as follows,
{
user: {
id:"c5667fb4-2348-4ccc-afc4-2309077a09ad"
documents :[
{
type:"PASSPORT",
value:"1234"
issue_date:"11/11/2011"
},
{
type:"DRIVING_LICENSE",
value:"5678"
issue_date:"11/11/2001"
}
]
}
}
For a given user that a client is interested in, I need to be able to evaluate and respond through my API and ask for any of the missing documents - Like for example a user might have provided only PASSPORT on creation time so I need to now ask only for DRIVING_LICENSE.
For this I was thinking of a controller endpoint(like an "evaluate") to be able to send a response that indicates what data the user is missing.
the client can invoke POST: /evaluate/c5667fb4-2348-4ccc-afc4-2309077a09ad
and now say that this user is missing DRIVING_LICENSE the response should indicate what is missing like follows - I am using json path to define what I am looking for
{
required_data:[
{
path:"user.documents[?(@.type=="DRIVING_LICENSE")].type"
}
]
}
Is this a reasonable way to express this requirement or is there a more correct way to do this?
rest jsonpath
rest jsonpath
asked Nov 21 '18 at 11:53
user3738616user3738616
31
31
I feel that the general title of the question is too broad. Are both passpord AND driving license necessary in your use case? If yes, should partial uploads of such documents be supported? If so, you need a way to attach the document to the initial request. There are a couple of ways to achive this. In HTML i.e. you return a form to tell the client what information is needed/missing. By using custom, over-generic (plain JSON) media-types a client needs out-of-band information on processing such a request, which is a bit against RESTs intention TBH.
– Roman Vottner
Nov 21 '18 at 13:52
Apologies if the title is not specific enough. The use case here is something like the user is trying to apply for a new product which requires a some more information to be collected as generally(for us) the information provided at onboarding(user creation) is pretty minimal. To give some more context, this is for a mid tier component that houses what data is needed for a specific product and hence I was alluding towards how to do this via APIs.
– user3738616
Nov 21 '18 at 15:44
In general the best advice in terms of REST architecture given is to design the interaction flow as if you deal with a browser-based service that ships HTML pages. You might replace HTML with JSON, though the important segments like forms and such should be present in this representation format as well. The syntax used as well as the semantics of elements should be defined as closely as possible to avoid confusion. Ideally you'd also register such a media type with IANA
– Roman Vottner
Nov 21 '18 at 17:10
add a comment |
I feel that the general title of the question is too broad. Are both passpord AND driving license necessary in your use case? If yes, should partial uploads of such documents be supported? If so, you need a way to attach the document to the initial request. There are a couple of ways to achive this. In HTML i.e. you return a form to tell the client what information is needed/missing. By using custom, over-generic (plain JSON) media-types a client needs out-of-band information on processing such a request, which is a bit against RESTs intention TBH.
– Roman Vottner
Nov 21 '18 at 13:52
Apologies if the title is not specific enough. The use case here is something like the user is trying to apply for a new product which requires a some more information to be collected as generally(for us) the information provided at onboarding(user creation) is pretty minimal. To give some more context, this is for a mid tier component that houses what data is needed for a specific product and hence I was alluding towards how to do this via APIs.
– user3738616
Nov 21 '18 at 15:44
In general the best advice in terms of REST architecture given is to design the interaction flow as if you deal with a browser-based service that ships HTML pages. You might replace HTML with JSON, though the important segments like forms and such should be present in this representation format as well. The syntax used as well as the semantics of elements should be defined as closely as possible to avoid confusion. Ideally you'd also register such a media type with IANA
– Roman Vottner
Nov 21 '18 at 17:10
I feel that the general title of the question is too broad. Are both passpord AND driving license necessary in your use case? If yes, should partial uploads of such documents be supported? If so, you need a way to attach the document to the initial request. There are a couple of ways to achive this. In HTML i.e. you return a form to tell the client what information is needed/missing. By using custom, over-generic (plain JSON) media-types a client needs out-of-band information on processing such a request, which is a bit against RESTs intention TBH.
– Roman Vottner
Nov 21 '18 at 13:52
I feel that the general title of the question is too broad. Are both passpord AND driving license necessary in your use case? If yes, should partial uploads of such documents be supported? If so, you need a way to attach the document to the initial request. There are a couple of ways to achive this. In HTML i.e. you return a form to tell the client what information is needed/missing. By using custom, over-generic (plain JSON) media-types a client needs out-of-band information on processing such a request, which is a bit against RESTs intention TBH.
– Roman Vottner
Nov 21 '18 at 13:52
Apologies if the title is not specific enough. The use case here is something like the user is trying to apply for a new product which requires a some more information to be collected as generally(for us) the information provided at onboarding(user creation) is pretty minimal. To give some more context, this is for a mid tier component that houses what data is needed for a specific product and hence I was alluding towards how to do this via APIs.
– user3738616
Nov 21 '18 at 15:44
Apologies if the title is not specific enough. The use case here is something like the user is trying to apply for a new product which requires a some more information to be collected as generally(for us) the information provided at onboarding(user creation) is pretty minimal. To give some more context, this is for a mid tier component that houses what data is needed for a specific product and hence I was alluding towards how to do this via APIs.
– user3738616
Nov 21 '18 at 15:44
In general the best advice in terms of REST architecture given is to design the interaction flow as if you deal with a browser-based service that ships HTML pages. You might replace HTML with JSON, though the important segments like forms and such should be present in this representation format as well. The syntax used as well as the semantics of elements should be defined as closely as possible to avoid confusion. Ideally you'd also register such a media type with IANA
– Roman Vottner
Nov 21 '18 at 17:10
In general the best advice in terms of REST architecture given is to design the interaction flow as if you deal with a browser-based service that ships HTML pages. You might replace HTML with JSON, though the important segments like forms and such should be present in this representation format as well. The syntax used as well as the semantics of elements should be defined as closely as possible to avoid confusion. Ideally you'd also register such a media type with IANA
– Roman Vottner
Nov 21 '18 at 17:10
add a comment |
1 Answer
1
active
oldest
votes
If some mandatory information is missing in the request then this is error case and in this case it is better to provide 400 error HTTP code and error response body. So something like this
HTTP Error Code: 400
Error json body:
{
"errorCode": "Validation",
"message": "Driving license is required"
}
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
});
}
});
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%2f53411484%2fdata-collection-best-practice-using-rest-apis%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
If some mandatory information is missing in the request then this is error case and in this case it is better to provide 400 error HTTP code and error response body. So something like this
HTTP Error Code: 400
Error json body:
{
"errorCode": "Validation",
"message": "Driving license is required"
}
add a comment |
If some mandatory information is missing in the request then this is error case and in this case it is better to provide 400 error HTTP code and error response body. So something like this
HTTP Error Code: 400
Error json body:
{
"errorCode": "Validation",
"message": "Driving license is required"
}
add a comment |
If some mandatory information is missing in the request then this is error case and in this case it is better to provide 400 error HTTP code and error response body. So something like this
HTTP Error Code: 400
Error json body:
{
"errorCode": "Validation",
"message": "Driving license is required"
}
If some mandatory information is missing in the request then this is error case and in this case it is better to provide 400 error HTTP code and error response body. So something like this
HTTP Error Code: 400
Error json body:
{
"errorCode": "Validation",
"message": "Driving license is required"
}
answered Nov 21 '18 at 12:55


MaraMara
1,1851714
1,1851714
add a comment |
add a comment |
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.
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%2f53411484%2fdata-collection-best-practice-using-rest-apis%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
I feel that the general title of the question is too broad. Are both passpord AND driving license necessary in your use case? If yes, should partial uploads of such documents be supported? If so, you need a way to attach the document to the initial request. There are a couple of ways to achive this. In HTML i.e. you return a form to tell the client what information is needed/missing. By using custom, over-generic (plain JSON) media-types a client needs out-of-band information on processing such a request, which is a bit against RESTs intention TBH.
– Roman Vottner
Nov 21 '18 at 13:52
Apologies if the title is not specific enough. The use case here is something like the user is trying to apply for a new product which requires a some more information to be collected as generally(for us) the information provided at onboarding(user creation) is pretty minimal. To give some more context, this is for a mid tier component that houses what data is needed for a specific product and hence I was alluding towards how to do this via APIs.
– user3738616
Nov 21 '18 at 15:44
In general the best advice in terms of REST architecture given is to design the interaction flow as if you deal with a browser-based service that ships HTML pages. You might replace HTML with JSON, though the important segments like forms and such should be present in this representation format as well. The syntax used as well as the semantics of elements should be defined as closely as possible to avoid confusion. Ideally you'd also register such a media type with IANA
– Roman Vottner
Nov 21 '18 at 17:10