How can I distinguish a detail or list REST method in tastypie - tastypie

How can I find out if a GET method is requesting a detailed resource (example.com/api/v1/entry/1/) or a listing (example.com/api/v1/entry/)
What I am trying to do is to record how many times a detail GET method is called.
An option is to inspect the request object and get the PATH and see if a resource id was provided. However, I want to know if there's a better way to do this using tastypie's methods.

Override method get_detail.
def get_detail(self, request, **kwargs):
# Your custom code for incrementing GET counter
return super(YourResource, self).get_detail(request, **kwargs)
That method is called every time the get details method is requested.

Related

Pass ID or Object which has irrelavant details as RequestBody in Rest Call?

Approach 1:
#PostMapping("/api/{id}")
String getSomeObj(int id){
//make another rest call with id and get CustomObj
// then do some logic and return something
//Here response time will be more as it has again another rest calls
}
Approach 2:
#PostMapping("/api/{id}")
String getSomeObj(#PathParam("id") int id, #RequestBody CustomObj obj){
//directly do logic with the provided obj and return something
//Here Response time would be less as we are directly getting the actual Object from Request Body
//BUT is this a good practise to pass an object in which we need only few details?
}
Q1) All I am asking is to whether to pass just id or Object? If id is passed, another Rest call has to be made unnecessarily. If Object is passed, we can avoid making another rest call, BUT the problem is: this custom object may contain some irrelavant details too.. So, is this correct?
Q2) If passed with id, response time will be more when comparing with just passing object.. So, I am not understanding which approach should follow..
A1) This is all up to you and there is no "one correct" way. I would say if it's a small object pass the object and respond fast. If its a big object pass the id. How do you define big and small objects? if object has hashmaps or lists in it that's a big object. Also you can ignore serialization of internals; check https://www.baeldung.com/jackson-ignore-properties-on-serialization
A2) Pass the id and enjoy your REST service. After all REST is very fast. Don't worry about the speed of calls. If your back end function is fast and if you put a "loading" gif to front end; users will wait for the response.

REST API to check if an object exists

I have currently a webservice that load an object which looks like /object/load?id=100, the problem is that my object is really huge and it takes a long time to get the full response of the webservice just to see if the object exists or not.
What is the best pratice here ?
Creating a new webservice /object/exists?id=100 thats only use HTTP status code (200 if object exists, 404 if not) ?
Add parameter to the /object/load webservice to return only simplified object ?
If you are only interested in existence, or knowing in advance how the API will respond if you do a real GET request, HTTP actually has a built-in method for that: HEAD.
I'd recommend creating a new method within your existing web service. Name that method 'Exists' or something similar, and make sure that it is a HttpGET method.
You could then pass in the ID of the object you want to check, then within the method just do a check to see if the object exists. If the object exists you should return true, else return false.

Can you add an object that is available in the request context only?

In Spring (java) and in .NET also, you can add an object in request scope?
i.e. a user makes a request, you perform some look in a filter or base controller, and then you can add this object into the request object for this current request only
Now in your Action you can check if the key exists and use this object in your action method.
In Play 2 Requests are immutable so you would generally wrap them and pass them around rather than modifying them.
You'd usually use something called action composition to do what you want. Action composition lets you write common code for actions so that you can pre-process a requests and maybe pass the action some data from the request.
Check out the Authenticated example in the docs which provides the action with an AuthenticatedRequest object. The AuthenticatedRequest object wraps the existing Request (rather than modifying it) and adds an additional username value.
As Rich said, you can use Action Composition and, if you want to put more information in Request context, you can use Http.current().args.put("key","value").

Extending CQ5 List component

I'm looking into extending the cq5 list component to create custom list displays (obviously). The constructor takes a SlingHttpServletRequest and the minimal java doc says "creates a list from the specified request".
Can someone explain how those request settings are used to build the list? what things in the request should I change to alter the list? Is there better documentation somewhere?
The component uses the request to retrieve the resource object.
In the init method it retrieves a the resource node's properties.
The "listFrom" property should matter for you the most as it controls how the list is created. Either by querybuilder, search, retrieving the children ("children") or tags.
The List component does a simple string equals to find out which option is set and executes the associated logic.
At the end a PageIterator is returned, which is processed by the jsp.

Using different delegates for NSXmlParser

I am trying to figure out the best way to design something. I am writing an iPhone App and for the most part I am using async calls to a web service. This means that I cam setting up a URLConnection, calling start and letting it call me back when the data is available or an exception occurs. This works well and I think is the correct way to handle things.
For example:
I request a list of people from a web service. The resulting list is Xml Person elements which will be translated into an objective-c "Person" object by my XmlDelegate.
When I call the function to get the person, I pass in a "PersonResultDelegate", which is a protocol with a single function called "PersonReceived:(Person *)p". So, each time I get a complete Person object, I call that method and all is well. So, my detail view (or search result view) just receives the elements as they are available.
The problem comes when I need to obtain more then one specific object. In my specific case, I need to get the first and last appointment for a person. So, I need to make two API calls to obtain these two single Appointment objects. Each Appointment object will result in a call to the registered AppointmentResultDelegate, but how will I know which is the first and which is the last? I also need to somehow handle the case when there is no "first" or "last" Appointments and the Delegate will never get called.
What would be the correct way design wise to handle this? Should I add some additional context information to the initial request which is passed back to the handle in the delegate? An opaque piece of data which only makes sense to the person who made the initial call? What are my other options?
Solution
What I actually ended up doing is just passing an opaque piece of data along with the Appointment to the delegate. So, when I request an appointment object I have a method like:
getNextAppointment withDelegate:self withContext:#"next"
getPrevAppointment withDelegate:self withContext:#"prev"
This way when the delegate gets called I know what appointment is being delivered.
"Each Appointment object will result in a call to the registered AppointmentResultDelegate, but how will I know which is the first and which is the last?"
By looking at the order in which you receive these callbacks. Or by looking at some value in that xml data. Like a sequence or data. I don't know your data of course.