1

No code to show (and not really a code issue) but I have an iot-ish application running that is using PI Zeroes as clients and they are slow. A single POST takes about 10 seconds round trip, the delay seems to be almost entirely within the client side Python script, possibly related to slow connections but I would like to POST/log more than 1 entity every 10 seconds.

I think about POSTing an array or other collection of values which should be more efficient but I am not sure that is very "RESTful". What do I return? A single status code across all entities? Is there a different HTTP Verb that I should consider? The client will never use the new IDs on the POSTed entities or requery them so that isn't an issue.

Bottom line is it reasonable to POST multiple models and then return a collection of the multiple resulting entities each with their own IDs? Better to POST arrays or embed them within a single parent container object?

Lastly my API call is somewhat asymmetric. The data being sent to the API does not model 1:1 the data being stored in my database further lowering the value of any returned data from my POST.

  • As an side to the good questions already present: http supports multiple entities per request with multipart messages. You can set a custom header in each entity for reference in the response. You can then also respond with a multipart from the server; a response entity for every one in the request, reuisng the reference header. – marstato Jul 5 '19 at 17:40
2

I think about POSTing an array or other collection of values which should be more efficient but I am not sure that is very "RESTful". What do I return? A single status code across all entities? Is there a different HTTP Verb that I should consider?

REST doesn't prevent posting array of objects. You can read more about REST here. Whether to return a single status code across all entities depends on whether these are a part of a transaction. I am assuming it is not, so it will be better to return a status code for each entity indicating success or failure. POST/PUT/DELETE corresponds to create/update/delete operations. But in practice if sending a single large collection to be updated in the database(irrespective if it involves create/update/delete) I would use POST/PUT.

The client will never use the new IDs on the POSTed entities or requery them so that isn't an issue.

Since you are not using any data from the creation of new entries in the db, you don't need to return them at all. You can simply return an array of messages indicating which updates were successful.

Better to POST arrays or embed them within a single parent container object?

You don't need to create a parent object. Since an array of objects is valid JSON, you can send it to server without modification.

| improve this answer | |
2

S: I think about POSTing an array or other collection of values which should be more efficient but I am not sure that is very "RESTful".

REST is an architectural style. It has nothing to do with the things we send. Sending resources one by one or arrays is not as important as the format or the semantics implied in the client-server communication.

Q: What do I return? A single status code across all entities?

Yes. Why not? Say we send 200 OK. What we say is, Everything went ok. The request has been sent and processed successfully. For more details, you could respond with a little report in the response body.

If you can not allow failures in any of the elements of the array, I would suggest failing fast. As soon as one of the elements cannot be processed, the business transaction gets interrupted and the code status change to 4xxor 5xx HTTP status code.

Q: Is there a different HTTP Verb that I should consider?

POST is ok. If you were replacing (or updating) a specific collection, I could consider PUT for a moment.

S: The client will never use the new IDs on the POSTed entities or require them so that isn't an issue.

Fine, instead of 200 OK you could respond with 201 No Content. If the array is not processed immediately, you could respond with 202 Accepted.

Q: Bottom line is it reasonable to POST multiple models and then return a collection of the multiple resulting entities each with their own IDs? Better to POST arrays or embed them within a single parent container object?

Depends. Which way do you think is the easier format to work with (on both sides client and server)?1 Which one do you think is more consistent (considering the Web API as a whole)?

Q: Lastly, my API call is somewhat asymmetric. The data being sent to the API does not model 1:1 the data being stored in my database further lowering the value of any returned data from my POST.

That's expected from representational state transfer-based applications. We might or might not represent our resources as they really are. Say we represent files in the file system. The representation could be something similar to {"name": "file.text", "mime-type":"plain/text", "size":"1", "permissions":"666", "owner":"me"} and the real resource would be a binary in the file system. The same happens with the persistence model.2


1: I'm an advocate of the second embed them within a single parent container object

2: Ideally, the more decoupled are both models the better.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.