While developing Web API, what to prefer, Web API standards or the performance? For example, to update(PUT) a group of object (changing one of their properties to a common value), I can accept a list of objects and update them with optimizing the performance Count(object) times.
Asked
Active
Viewed 135 times
2 Answers
0
Since there are no real rules on how to implement a RESTful API, this is up to you.
If you can make everyone's life a little easier by supporting bulk PUTting, go ahead and do it.
Just think about it. Say you have to update 100 resources, do you want to do 1 call, or 100? 100 seperate calls could potentially be expensive, as in performance and time spent.
It can also depend on how your server is implemented. In the 1st question I linked to at the bottom of this answer it is mentioned that doing bulk requests could cause problems when you want to support error reporting.
Whatever you choose, just make sure the user of the API knows exactly how to form a valid request and what response he can expect.
Also see
RESTful way to create multiple items in one request
-
yeah right.I'll have to implement an "Error Report" generating code. But it worth the performance gain. – ime Jun 20 '14 at 10:19
-
@ime Yeah I agree it's probably worth the gain, especially if you are working with a system that limits the amount of api calls you can make per day – Tim Jun 20 '14 at 10:22
0
Most clients will perform better if they can issue fewer requests to fetch or modify more data. It’s a good idea to build bulk operations into your API to support this kind of use case.
If you're so interested in performance, it's worth considering the following:
Connection: Keep-Alive: Maintaining a connection with your API server for multiple API requests can be a big performance improvement. Pretty much every web server should support keep-alive connections if configured correctly. Some HTTP client libraries require you to do some extra work to enable persistent connections. Persistent connections can have a significant impact on the perceived performance of your API.
Expect: 100-Continue: If an API client is about to send a request with a large entity body, like a POST, PUT, or PATCH, they can send “Expect: 100-continue” in their HTTP headers, and wait for a “100 Continue” response before sending their entity body. This allows the API server to verify much of the validity of the request before wasting bandwidth to return an error response (such as a 401 or a 403). Supporting this functionality is not very common, but it can improve API responsiveness and reduce bandwidth in some scenarios. (RFC2616 §8.2.3).
HTTP Compression: HTTP compression can be used both for response bodies (Accept-Encoding: gzip) and for request bodies (Content-Encoding: gzip) to improve the network performance of an HTTP API.
Maximising performance is admirable but, at the end of the day, if you're pressed for time and need to deliver something, you need to be pragmatic and get on with things.
