1

I have to design a REST API to support a locationBasedService Application, the location is the main resource in the system with the following services :

  1. Create a location by filling a form, location data includes name, coordinates, description and image
  2. Create more than one location by uploading a JSON file. Image will be null in this case
  3. Update a location. Location data will be edited from a form similar to the one from which it was created

My main problem is related to the file part of the location data. I read a lot of questions related to this and I came to the following two designs:

  1. encode the file data as base64 and send the file part of the JSON data, (limitations: image size), the rest API will be as follows:

    /lbs/admin/locations PUT - for form creation

    /lbs/admin/locations POST - for update

    /lbs/admin/fileupload/location POST for file creation

  2. the second design considers sending two requests to the server, the first one to /lbs/admin/location with [PUT] where all data except file will be sent, the response will include the id of the created location, where another request will be [POSTED] to /lbs/admin/location/{id} with file data to be created

Now, do you have any better design and if I consider the second approach, how can I design the update location logic?

devlin carnate
  • 8,309
  • 7
  • 48
  • 82
Moon123
  • 153
  • 3
  • 15

1 Answers1

0

IMO, second design sounds good. You can have two different REST APIs for the business scenarios you have mentioned.

POST : /lbs/admin/locations - to create location - Response header contains location id which will be used to upload a file for a particular location.

PUT : /lbs/admin/locations/{id} - to upload a file. (Considering the fact that file is one of the attributes of location.)

But you may also wants to consider the use case where user may wants to upload the file along with sending location related information.

POST : /lbs/admin/locations/files - to create a location and and upload a file in a same API. (Feel free to change the URL based on your convention.)

In this case, location will be created first and newly created location id will be used for file upload. Both of these operations should be done on server side.

This API will help you to prevent two server trips if above mentioned use case is valid.

asg
  • 2,248
  • 3
  • 18
  • 26
  • Thanks for your reply, – Moon123 Apr 23 '16 at 13:21
  • Thanks for your reply, but what about the edit operation, according to rest best practices , the Method POST must be uset for update operation , i mean the URL lbs/admin/locations/{id}must be used for the update, do you have any idea – Moon123 Apr 23 '16 at 13:29
  • Your question is valid and it depends how two business entities are defined. Here I am considering two business entities as - location and file. Whether file can have a existence outside location scope? If yes, post is valid as you are creating new entity altogether which can be considered as file. But if file is tightly coupled with location and can't have existence without location, then it does make sense to have method as PUT as you are updating your location with one more attribute that is file. – asg Apr 23 '16 at 16:28
  • I have updated my answer. Please let me know in case of any questions. And thanks for pointing out! – asg Apr 23 '16 at 16:50
  • Yes, the image file cannot exist if the location is not created, anyway, i posted my solution, hope to give me your feedback – Moon123 Apr 24 '16 at 06:24
  • I came with the following design, highly appreciate anyone’s feedback Lbs/admin/loccations GET getAllLocations || Lbs/admin/locations/{id} GET getLocationByID || Lbs/admin/locations/{id} DELETE deleteLocation || Lbs/admin/locations PUT createLocation(only location data without image, return the id of the created location) || Lbs/admin/loccations/image/{id} POST setLocationImage (create and update the location of the image) || Lbs/admin/loccations/file POST createLocationsFromFile (receive JSON file to create a set of locationslocations) || Lbs/admin/locations /{id} POST updateLocationData – Moon123 Apr 24 '16 at 06:28
  • || Lbs/admin/locations GET getAllLocations – asg Apr 25 '16 at 06:44
  • || Lbs/admin/locations POST createLocation(only location data without image, return the id of the created location) – asg Apr 25 '16 at 06:44
  • || Lbs/admin/locations/{id} GET getLocationById – asg Apr 25 '16 at 06:44
  • || Lbs/admin/locations/{id} DELETE deleteLocation – asg Apr 25 '16 at 06:44
  • Above five were straight forward. I have changed a little. Please take a look. – asg Apr 25 '16 at 06:46
  • thanks, asg, but i know that POST is for update operations and PUT is for create operations, please correct me if i am wrong, – Moon123 Apr 25 '16 at 07:02
  • We use POST for creation and PUT for update operation.. but actually it is governed by the data you have right now. Refer to http://stackoverflow.com/questions/630453/put-vs-post-in-rest. [Better is to choose between PUT and POST based on idempotence of the action.] – asg Apr 25 '16 at 07:09
  • Hence, Lbs/admin/locations is POST and Lbs/admin/locations/{id} is PUT. – asg Apr 25 '16 at 07:09