I have a question.
In an interview, I was asked if one of the routes of scatter-gather fail, will we get the output. I replied with a no as scatter-gather always gives a consolidated payload taken from all routes, and then they asked me if I still want to get the payload from the successful routes, what should I do -> I answered with Try scope and on-error continue. (I hope I was right here, please explain if I wasn't).
The next scenario they gave me was like this: If I have an on-error-propagate set for the scatter-gather and I also have a payload in that. So when the route fails and the handler comes to on-error-propagate, will the payload present there be printed or not. My answer to this question was a yes and I said that because on-error-propagate executes all its steps, the payload present inside its scope will be printed and then the flow will exit.
I don't know if that was right or not, so please help me with the correct answer for this scenario.
I'm not sure if this is the right platform for these question but I'll try to answer them.
I was asked if one of the routes of scatter-gather fail, will we get the output. I replied with a no as scatter-gather always gives a consolidated payload taken from all routes
Scatter-gather executes all routes simultaneously and generates a LinkedHashMap of all the Mule Events (not just payloads). The payload from each event can certainly be extracted or functions like flatten() can be used to flatten the contents linearly. If one of the routes fail and no error handling is done, an error object will be introduced and scatter-gather will fail.
they asked me if I still want to get the payload from the successful routes, what should I do -> I answered with Try scope and on-error continue.
Your answer seems good to me. Although, please note that on-error-continue should be on another flow that scatter-gather is calling. Having it in the same flow as scatter-gather may suppress the error raised but will not continue executing the next component in same flow.
If I have an on-error-propagate set for the scatter-gather and I also have a payload in that. So when the route fails and the handler comes to on-error-propagate, will the payload present there be printed or not.
The statement is a bit confusing to me as it doesn't specify the placement of the on-error-propagate. If a printing component is inside the on-error-propagate scope and the handler comes to on-error-propagate, it will certainly print. However, if all it has is the payload, the flow will never go to the next component and an error object will be returned to the parent flow (or error is thrown if there's no parent flow).
Related
I was accessing REST calls, when I passed wrong parameter to GET request it does not throw any http error. Should the design be changed to throw a http error or wrong parameter can be passed to REST call.
Example 1:(parameters are optional)
https://example.com/api/fruits?fruit=apple
Give list of all apple elements
Example 2:
https://example.com/api/fruits?abc=asb
Give list of all fruits
My question is related to example 2, should example 2 throw an error or is it behaving properly?
It's pretty common to ignore parameters that you aren't necessarily expecting. I think example 2 is behaving as it should.
I know that depending on the browser I would sometimes append an extra variable with a timestamp to make sure that the rest call wouldn't be cached. Something like:
https://example.com/api/fruits?ihateie=2342342342
If you're not explicitly doing anything with the extra parameter then I can't see the harm in allowing it.
For a GET request, the request-line is defined as follows
request-line = 'GET' SP request-target SP HTTP-version CRLF
where request-target "...identifies the target resource upon which to apply the request".
That means that the path /api/fruits, the question-mark ? and the query abc=asb are all part of the identifier.
The fact that your implementation happens to use the path to route the request to a handler, and the query to provide arguments, is an accident of your current implementation.
That leaves you with the freedom to decide that
/api/fruits?abc=asb does exist, and its current state is a list of all fruits
/api/fruits?abc=asb does exist, and its current state is an empty list
/api/fruits?abc=asb does exist, and its current state is something else
/api/fruits?abc=asb does not exist, and attempting to access its current state is an error.
My question is related to example 2, should example 2 throw an error or is it behaving properly?
If abc=asb indicates that there is some sort of error in the client, then you should return a 4xx status to indicate that.
Another way of thinking about the parameter handling is in terms of Must Ignore vs Must Understand.
As a practical matter, if I'm a consumer expecting that my filter is going to result in a small result set, and instead I end up drinking a billion unfiltered records out of a fire hose, I'm not going to be happy.
I'd recommend that in the case of a bad input you find a way to fail safely. On the web, that would probably mean a 404, with an HTML representation explaining the problem, enumerating recognized filters, maybe including a web form that helps resend the query, etc. Translate that into your API in whatever way makes sense.
But choosing to treat that as a successful request and return some representation also works, it's still REST, the web is going to web. If doing it that way gives you consumers a better experience, thereby increasing adoption and making your api more successful, then the answer is easy.
One of our APIs has a tasks resource. Consumers of the API might create, delete and update a given task as they wish.
If a task is completed (i.e., its status is changed via PUT /tasks/<id>), a new task might be created automatically as a result.
We are trying to keep it RESTful. What would be the correct way to tell the calling user that a new task has been created? The following solutions came to my mind, but all of them have weaknesses in my opinion:
Include an additional field on the PUT response which contains information about an eventual new task.
Return only the updated task, and expect the user to call GET /tasks in order to check if any new tasks have been created.
Option 1 breaks the RESTful-ness in my opinion, since the API is expected to return only information regarding the updated entity. Option 2 expects the user to do stuff, but if he doesn't then no one will realize that a new task was created.
Thank you.
UPDATE: the PUT call returns an HTTP 200 code along the full JSON representation of the updated task.
#tophallen suggests having a task tree so that (if I got it right) the returned entity in option 2 contains the new task as a direct child.
You really have 2 options with a 200 status PUT, you can do headers (which if you do, check out this post). Certainly not a bad option, but you would want to make sure it was normalized site-wide, well documented, and that you didn't have anything such as firewalls/F5's/etc/ re-writing your headers.
Something like this would be a fair option though:
HTTP/1.1 200 OK
Related-Tasks: /tasks/11;/tasks/12
{ ...task response... }
Or you have to give some indication to the client in the response body. You could have a task structure that supports child tasks being on it, or you could normalize all responses to include room for "meta" stuff, i.e.
HTTP/1.1 200 OK
{
"data": { ...the task },
"related_tasks": [],
"aggregate_status": "PartiallyComplete"
}
Something like this used everywhere (a bit of work as it sounds like you aren't just starting this project) can be very useful, as you can also use it for scenarios like paging.
Personally, I think if you made the related_tasks property just contain either routes to call for the child tasks, or id's to call, that might be best, lighter responses, since the client might not always care to call to check on said child-task immediately anyways.
EDIT:
Actually, the more I think about it - the more headers would make sense in your situation - as a client can update a task at any point during the task processing, there may or may not be a child task in play - so modifying the data structure for the off-chance the client calls to update a task when a child task has started seems more work than benefit. A header would allow you to easily add a child task and notify the user at any point - you could apply the same thing for a POST of a task that happens to immediately finish and kicks off a child task, etc. It can easily support more than one task. I think this as well keeps it the most restful and reduces server calls, a client would always be able to know what is going on in the process chain. The details of the header could define, but I believe it is more traditional in a scenario like this to have it point to a resource, rather than a key within a resource.
If there are other options though, I'm very interested to hear them.
It looks like you're very concerned about being RESTful, but you're not using HATEOAS, which is contradictory. If you use HATEOAS, the related entity is just another link and the client can follow them as they please. What you have is a non-problem in REST. If this sounds new to you, read this: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Option 1 breaks the RESTful-ness in my opinion, since the API is
expected to return only information regarding the updated entity.
This is not true. The API is expected to return whatever is documented as the information available for that media-type. If you documented that a task has a field for related side-effects tasks, there's nothing wrong with it.
How can I "Fire and forget" certain requests, such as DELETE or PUT or even some POST, with RK?
I've been googling and have found a solution, but I have to believe there is an easier way that I'm missing. This is what I have:
Model: Room
Room GET request: I set up RKObjectMapping, RKResponseDescriptor, route(responds to 200) <--- works perfectly
Room DELETE request: I set up RKObjectMapping, RKResponseDescriptor, route(responds to 204) <--- works perfectly
My question is: Is there an easier way to do this?
Maybe I'm being lazy, but setting up RKObjectMapping, RKResponseDescriptor for every action seems like a lot of extra work if I don't plan on doing anything with the response. (Note: even error handling isn't necessary.)
I'm relatively new to restkit, sorry if I'm missing something obvious. Any advice would be appreciated.
Thanks for indulging my laziness :)
If you don't care about the response (or even the result status) then you don't need to define response descriptors. Technically RestKit will raise an error result because no response descriptors could be found but that doesn't matter to you.
If you aren't using the get/put/post object methods then an alternative would be to define a single mapping to an NSDictionary. The mapping could have a single key (or it may work with no keys). Then, for any request where you don't care about the response you can provide a valid mapping which is basically a no-op.
Another alternative is to write a single method which takes a Class and returns an empty response descriptor. You'll still have some configuration calls but much less code.
In regard to potential runtime failures, like database queries, it seems that one must use some form of Either[String, Option[T]] in order to accurately capture the following outcomes:
Some (record(s) found)
None (no record(s) found)
SQL Exception
Option simply does not have enough options.
I guess I need to dive into scalaz, but for now it's straight Either, unless I'm missing something in the above.
Have boxed myself into a corner with my DAO implementation, only employing Either for write operations, but am now seeing that some Either writes depend on Option reads (e.g. checking if email exists on new user signup), which is a majorly bad gamble to make.
Before I go all-in on Either, does anyone have alternate solutions for how to handle the runtime trifecta of success/fail/exception?
Try Box from the fantastic lift framework. It provides exactly what you want.
See this wiki (and the links at the top) for details. Fortunately lift project is well modulized, the only dependency to use Box is net.lift-web % lift-common
Use Option[T] for the cases records found and no records found and throw an exception in the case of SQLException.
Just wrap the exception inside your own exception type, like PersistenceException so that you don't have a leaky abstraction.
We do it like this because we can't and don't want to recover from unexpected database exceptions. The exception gets caught on the top level and our web service returns a 500 Internal server error in such case.
In cases where we want to recover we use Validation from scalaz, which is much like Lift's Box.
Here's my revised approach
Preserve Either returning query write operations (useful for transactional blocks where we want to rollback on for comprehension Left outcome).
For Option returning query reads, however, rather than swallowing the exception with None (and logging it), I have created a 500 error screen, letting the exception bubble up.
Why not just work with Either result type by default when working with runtime failures like query Exceptions? Option[T] reads are a bit more convenient to work with vs Either[Why-Fail, Option[T]], which you have to fold/map through to get at T. Leaving Either to write operations simplifies things (all the more so given that's how the application is currently setup, no refactoring required ;-))
The only other change required is for AJAX requests. Rather than displaying the entire 500 error page response in the AJAX status div container, we check for the status type and display 500 error message accordingly.
if(data.status == 500)
$('#status > div').html("an error occurred, please try again")
Could probably do an isAjax check server-side prior to sending the response; in which case I can send back only status + message rather than the error page itself.
I'm a newbie to WF and rather lost. Here's what I have so far:
I've created a workflow service app (xamlx), added needed variables
I've created a custom NativeActivity where I'm calling CreateBookmark from within Execute, which is between the Receive & Send activity for the service. (Ultimately this will actually do something besides creating the bookmark).
The bookmark gets created just fine, but after stepping out of the Execute method, nothing happens for one minute until the service times out, giving me that message "The request channel timed out while waiting for a reply after 00:00:59.9699970. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout." (I tried posting an image of the xamlx, but as a newbie it won't let me; suffice it to say I'm getting from my Receive, into my custom native activity, but never getting as far as the SendReply).
I assume I'm missing something rather fundatmental, but I can't see what. I've originally tried using NativeActivity<T> to return what I want, but that behaves the same.
Found out what I was doing wrong: needed to use overload of CreateBookmark that has BookmarkOptions parameter and set it to BookmarkOptions.NonBlocking.
Strangely, I did not find one example anywhere that mentioned this.