Timeline for Best way to represent multiple JSON response in a REST service?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 23, 2016 at 19:46 | comment | added | david |
I am querying information related to a particular user. I mean given a userid, we retrieve information related to that user and that information will be in a JSON string as shown in inside response variable and then some other information in other variables as well. So in this case what do you think will be a good variable name. I am having hard time figuring out this.
|
|
| Jan 22, 2016 at 21:34 | comment | added | dubmojo | Name it something that reflects the object/data being retrieved. "response" is a generic name. If you're querying the status of some sales order, calling it "orders -> order -> status" would be better. Easy to read and understand data structures are always recommended. Good luck. | |
| Jan 21, 2016 at 22:42 | comment | added | david |
hey one more basic question. If you would like to rename response field in the json response which one you would rename and what you would like to rename it with? I am having hard time figuring out what name I should give? I was thinking to change outermost response field to some other name.
|
|
| Dec 24, 2015 at 2:17 | vote | accept | david | ||
| Dec 10, 2015 at 14:44 | comment | added | dubmojo | You can technically return any HTTP status in every case where your queries complete successfully but are empty, where they're all full, where there's a mix of full/empty and errors. I would reserve 500 for actual REST service failures. I don't know if your query failures are real errors (caught exception, etc...) or some overloaded combination along with field validation, reasons for the uery being empty, etc... You're defining the REST service and how its used. Handling multiple error states from a single status code will only be a shortcut for the requesting side only how to deal with it. | |
| Dec 9, 2015 at 21:51 | comment | added | david | Yes I do understand but I do need to return some status code back right? | |
| Dec 9, 2015 at 21:36 | comment | added | dubmojo | This is kind of open to interpretation a bit and depends on the complexity of your REST interactions. I mean HTTP status codes won't tell which or why some bulk queries failed. If you want to short cut having to deserialize the JSON to check, then a HTTP status can be way more direct. Look at the 4xx HTTP status codes. The 5xx and 500 should saved for bigger communication issues. You want to minimize overloading the meaning of HTTP status codes. It can lead to confusion later when trying to debug the system. | |
| Dec 8, 2015 at 21:53 | comment | added | david | Thanks. Also, let's say in my JSON array all three request failed and there are different error messages for each request then what's the HTTP Status code my REST Service should return back? I mean all those three errors failed with different messages so what status code my rest service will return? | |
| Dec 8, 2015 at 21:07 | comment | added | dubmojo | See my updated answer. | |
| Dec 8, 2015 at 21:07 | history | edited | dubmojo | CC BY-SA 3.0 |
added 1087 characters in body
|
| Dec 8, 2015 at 17:13 | comment | added | david | Thanks garlicman. In this case, json response is going to be same what I had earlier or it will be slightly different? Can you provide an example for that as well? | |
| Dec 8, 2015 at 2:46 | review | First posts | |||
| Dec 8, 2015 at 3:56 | |||||
| Dec 8, 2015 at 2:44 | history | answered | dubmojo | CC BY-SA 3.0 |