I am quite new new to Smartsheets and to programming.
I am using Integromat to update various stuff in Smartsheets - 99% operations are done via a nice interface for dummies.
But I have an issue with one column which is MULTI_PICKLIST and which cannot be processed with native dummy-friendly UI.
Basically, I'm adding a new row and one of the columns on the way is the MULTI_PICKLIST one. In order to enter value into this cell, I need to make an arbitrary HTTP API call.
I know row ID, I know column ID. I just need to construct the body of the HTTP request.
The possible picklist value are: John or Maya or Paul. Assume I need to enter "John" into the column.
Attached, you will find my "progress". I obviously, I'm stuck with the BODY part. Can someone give me a little push, please? I think it's gotta be like 5 lines of code.
This is what I have:
DZ
A few things...
First, the value that you're using for URL doesn't look quite right. It should be in the following format, where {sheetId} is replaced with the ID of the sheet you're updating:
sheets/{sheetId}/rows
Second, I don't think you need the key/value that you've specified for Query String -- I'd suggest that you delete this info.
Next, I'm not sure what the other possible values are for Type (based on your screenshot, it looks like a picklist) -- but if JSON is an option, I'd suggest choosing that option instead of Text.
Finally, here's any example of the correct structure/contents for Body to update a MULTI_PICKLIST cell with the value John -- replace the value of the id property (5225480965908356) with your Row ID and replace the value of the columnId property (8436269809198980) with your Column ID:
[
{
"id": "5225480965908356",
"cells": [
{
"columnId": "8436269809198980",
"objectValue": {
"objectType": "MULTI_PICKLIST",
"values": ["John"]
}
}
]
}
]
If you want to select multiple values for a MULTI_PICKLIST cell, here's an example that specifies two values for the cell (John and Maya):
[
{
"id": "5225480965908356",
"cells": [
{
"columnId": "8436269809198980",
"objectValue": {
"objectType": "MULTI_PICKLIST",
"values": ["John", "Maya"]
}
}
]
}
]
** UPDATE **
My initial answer answer above assumed you wanted to update a cell value in a MULTI-PICKLIST column (b/c you've selected PUT for the Method value in your screenshot -- which is the verb used to update a row). Having re-read your question just now though, it sounds like maybe you want to add a new row...is that correct? If so, then the value for Method should be POST (not PUT), and Body will need to include additional objects within the cells array to specify values of other cells in the new row. The following example request (when used with the verb POST) adds a new row and populates 3 cells in that row, the first of which is a MULTI_PICKLIST cell:
[
{
"cells": [
{
"columnId": "8436269809198980",
"objectValue": {
"objectType": "MULTI_PICKLIST",
"values": ["John"]
}
},
{
"columnId": 6101753539127172,
"value": "test value"
},
{
"columnId": 4055216160040836,
"value": 10
}
]
}
]
More info about the Add Rows request can be found in the Smartsheet API docs: Add Rows.
In a shopping cart application, suppose I have an endpoint for an endpoint for an /product/ for products that can be bought and a /cartitem/ for items in a shopping cart. Example of GET /product/2 response
{
"sku": "12345"
"name":"mars bar"
}
Example of a GET /cartitem/56
{
"quantity": 4
"sku": "12345"
"name":"mars bar"
}
When adding a cartitem, I will do a POST to /cartitem/ but instead of having to pass up the entire body, I'd like to able to just post a reference to the product
POST /cartitem
BODY:
{
"quantity": "4"
"product":"/product/2"
}
instead of having to do:
POST /cartitem/
{
"quantity": 4
"sku": "12345"
"name":"mars bar"
}
Note, I never want to have:
GET
{
"quantity": "4"
"product":"/product/2"
}
Reason is because there are multiple to ways to add a cartitem, sometimes you will have a product, sometimes you want. I want the response to not have to reference a product URI, but I want the POST to be allowed to reference it to make it easier for some clients.
Is that okay?
Thanks
You should use the primary key (ID) of the product instead of a link. The end result would be the same but its cleaner and makes more sense. You would just have to implement the logic for this.
Having 3 dropdown pickers in a web application. The web application uses a Restful service to populate pickers data.
The two first pickers get their values from something like /years and /colors. The third one should get its values depending on the settings of the two.
So it could be something like /models?year=1&color=red.
The question is, how to make this HATEOAS-compliant (so that the dev does not have to know the way he should create an url to get the models).
The root / gets me a number of links, such as:
{
"_links": {
"colors": "/colors",
"years": "/years",
"models": "???" }
}
What should be instead of ???? If there was some kind of template /models?color={color}&year={year}, the dev would have to create the url. Is this OK?
Or there could be a link to list of years on each color got from /colors and then a link to list of models on each year got from /years?color=red, but i'd have to first choose color, then populate years and then populate models. Any idea if i want to have the model dependent on both color and year, not just the year populated from color?
Is it even possible in this situation to make it hateoas-compliant?
I have not heard of HATEOAS before, but based on what I just read about it, it seems that it supposed to return links to where the consumer of the service can go forward in the "state machine".
In your case that would translate to the links being "function calls". The first two (/colors and /years) are functions that take no parameters (and return "something" at this point), while the third is a function call that takes two parameters: one that is a representation of a color, the other a year. For the first two having a simple URL will suffice for the link, but for the third, you need to include the parameter name/type information as well. Something like:
{
"_links": {
"colors": "/colors",
"years": "/years",
"models": {
"url": "/models",
"param1": {"color"}
"param2": {"year"}
}
}
}
Note: you can use the same layout as "models" for "colors" and "years" as well.
At this point the client knows what the URL to access the functions are and what the parameter (if any) names are to be passed to the function.
One more thing is missing: types. Although you could just use "string", it will not be obvious that the "color" parameter is actually a value from what "/colors" returns. You can be introducing a "type" Color that describes a color (and any functions that operate on a color: give a displayable name, HTML color code, etc.)
The "beefed up" signature becomes:
{
"_links": {
"colors": {
"url": "/colors",
"return": "/type/List?type=/type/Color"
},
"years": {
"url": "/years",
"return": "/type/List?type=/type/Integer"
},
"models": {
"url": "/models",
"param1": {
"name": "color",
"type": "/type/Color"
},
"param2": {
"name": "year",
"type": "/type/Integer"
}
"return": "/type/List?type=/type/Model"
}
}
}
Note: the path "/type" is used just to separate the types from functions, but is not necessary.
This will interchangeably and discoverably describe the functions, what parameters they take, and what values they are returning, so you can use the right value at the right place.
Of course implementing this on the service end will not be easy (especially with parameterized types, like "/type/List" -- think Generics in Java or templates in C++), but this is the most "safe" and "portable" way you can describe your interface to your clients.
I'd like to use a customized DomainClassMarshaller/ObjectMarshaller class in grails to get a nice paginated list.
I'd like the full like to appear something like this:
> GET /api/company/1/bookings
< 200 OK
{
"url": "/api/company/1/bookings",
"size": 42,
"pageSize": 10,
"nextPage": "/api/company/1/bookings/?page=2,
"prevPage": null,
"items": [
{ ... // booking 1
},
...
{ ... // booking 10
},
]
}
Whereas if there's has_a relationship between domain objects, and you get the parent object you'll just get the URL, which you can then dive into if necessary.
> GET /api/company/1
< 200 OK
{
"url": "/api/company/1"
...
"bookings": "/api/company/1/bookings"
}
However, if you're faced with a list of simple types, just go ahead and output them:
> GET /api/user/1
< 200 OK
{
"url": "/api/user/1",
"name" "Bob,
"favoriteThings": [
"Raindrops on roses",
"Whiskers on kittens",
"Bright copper kettles",
"Warm woolen mittens"
]
}
DomainClassMarshaller has a very nice little method called asShortObject which seems like it would do the trick.
My first thought would be to register a DomainClassMarshaller that only accepts Lists of domain classes, and another one that accepts simple lists. Is that the best approach?
Are there any resources out there on doing something similar to this? I can't believe I'm the first one to have this requirement.
Thanks for all your help,
David
I want to support pagination in my RESTful API.
My API method should return a JSON list of product via /products/index. However, there are potentially thousands of products, and I want to page through them, so my request should look something like this:
/products/index?page_number=5&page_size=20
But what does my JSON response need to look like? Would API consumers typically expect pagination meta data in the response? Or is only an array of products necessary? Why?
It looks like Twitter's API includes meta data: https://dev.twitter.com/docs/api/1/get/lists/members (see Example Request).
With meta data:
{
"page_number": 5,
"page_size": 20,
"total_record_count": 521,
"records": [
{
"id": 1,
"name": "Widget #1"
},
{
"id": 2,
"name": "Widget #2"
},
{
"id": 3,
"name": "Widget #3"
}
]
}
Just an array of products (no meta data):
[
{
"id": 1,
"name": "Widget #1"
},
{
"id": 2,
"name": "Widget #2"
},
{
"id": 3,
"name": "Widget #3"
}
]
ReSTful APIs are consumed primarily by other systems, which is why I put paging data in the response headers. However, some API consumers may not have direct access to the response headers, or may be building a UX over your API, so providing a way to retrieve (on demand) the metadata in the JSON response is a plus.
I believe your implementation should include machine-readable metadata as a default, and human-readable metadata when requested. The human-readable metadata could be returned with every request if you like or, preferably, on-demand via a query parameter, such as include=metadata or include_metadata=true.
In your particular scenario, I would include the URI for each product with the record. This makes it easy for the API consumer to create links to the individual products. I would also set some reasonable expectations as per the limits of my paging requests. Implementing and documenting default settings for page size is an acceptable practice. For example, GitHub's API sets the default page size to 30 records with a maximum of 100, plus sets a rate limit on the number of times you can query the API. If your API has a default page size, then the query string can just specify the page index.
In the human-readable scenario, when navigating to /products?page=5&per_page=20&include=metadata, the response could be:
{
"_metadata":
{
"page": 5,
"per_page": 20,
"page_count": 20,
"total_count": 521,
"Links": [
{"self": "/products?page=5&per_page=20"},
{"first": "/products?page=0&per_page=20"},
{"previous": "/products?page=4&per_page=20"},
{"next": "/products?page=6&per_page=20"},
{"last": "/products?page=26&per_page=20"},
]
},
"records": [
{
"id": 1,
"name": "Widget #1",
"uri": "/products/1"
},
{
"id": 2,
"name": "Widget #2",
"uri": "/products/2"
},
{
"id": 3,
"name": "Widget #3",
"uri": "/products/3"
}
]
}
For machine-readable metadata, I would add Link headers to the response:
Link: </products?page=5&perPage=20>;rel=self,</products?page=0&perPage=20>;rel=first,</products?page=4&perPage=20>;rel=previous,</products?page=6&perPage=20>;rel=next,</products?page=26&perPage=20>;rel=last
(the Link header value should be urlencoded)
...and possibly a custom total-count response header, if you so choose:
total-count: 521
The other paging data revealed in the human-centric metadata might be superfluous for machine-centric metadata, as the link headers let me know which page I am on and the number per page, and I can quickly retrieve the number of records in the array. Therefore, I would probably only create a header for the total count. You can always change your mind later and add more metadata.
As an aside, you may notice I removed /index from your URI. A generally accepted convention is to have your ReST endpoint expose collections. Having /index at the end muddies that up slightly.
These are just a few things I like to have when consuming/creating an API.
I would recommend adding headers for the same. Moving metadata to headers helps in getting rid of envelops like result , data or records and response body only contains the data we need. You can use Link header if you generate pagination links too.
HTTP/1.1 200
Pagination-Count: 100
Pagination-Page: 5
Pagination-Limit: 20
Content-Type: application/json
[
{
"id": 10,
"name": "shirt",
"color": "red",
"price": "$23"
},
{
"id": 11,
"name": "shirt",
"color": "blue",
"price": "$25"
}
]
For details refer to:
https://github.com/adnan-kamili/rest-api-response-format
For swagger file:
https://github.com/adnan-kamili/swagger-response-template
As someone who has written several libraries for consuming REST services, let me give you the client perspective on why I think wrapping the result in metadata is the way to go:
Without the total count, how can the client know that it has not yet received everything there is and should continue paging through the result set? In a UI that didn't perform look ahead to the next page, in the worst case this might be represented as a Next/More link that didn't actually fetch any more data.
Including metadata in the response allows the client to track less state. Now I don't have to match up my REST request with the response, as the response contains the metadata necessary to reconstruct the request state (in this case the cursor into the dataset).
If the state is part of the response, I can perform multiple requests into the same dataset simultaneously, and I can handle the requests in any order they happen to arrive in which is not necessarily the order I made the requests in.
And a suggestion: Like the Twitter API, you should replace the page_number with a straight index/cursor. The reason is, the API allows the client to set the page size per-request. Is the returned page_number the number of pages the client has requested so far, or the number of the page given the last used page_size (almost certainly the later, but why not avoid such ambiguity altogether)?
just add in your backend API new property's into response body.
from example .net core:
[Authorize]
[HttpGet]
public async Task<IActionResult> GetUsers([FromQuery]UserParams userParams)
{
var users = await _repo.GetUsers(userParams);
var usersToReturn = _mapper.Map<IEnumerable<UserForListDto>>(users);
// create new object and add into it total count param etc
var UsersListResult = new
{
usersToReturn,
currentPage = users.CurrentPage,
pageSize = users.PageSize,
totalCount = users.TotalCount,
totalPages = users.TotalPages
};
return Ok(UsersListResult);
}
In body response it look like this
{
"usersToReturn": [
{
"userId": 1,
"username": "nancycaldwell#conjurica.com",
"firstName": "Joann",
"lastName": "Wilson",
"city": "Armstrong",
"phoneNumber": "+1 (893) 515-2172"
},
{
"userId": 2,
"username": "zelmasheppard#conjurica.com",
"firstName": "Booth",
"lastName": "Drake",
"city": "Franks",
"phoneNumber": "+1 (800) 493-2168"
}
],
// metadata to pars in client side
"currentPage": 1,
"pageSize": 2,
"totalCount": 87,
"totalPages": 44
}
This is an interessting question and may be perceived with different arguments. As per the general standard meta related data should be communicated in the response headers e.g. MIME type and HTTP codes. However, the tendency I seem to have observed is that information related to counts and pagination typically are communicated at the top of the response body. Just to provide an example of this The New York Times REST API communicate the count at the top of the response body (https://developer.nytimes.com/apis).
The question for me is wheter or not to comply with the general norms or adopt and do a response message construction that "fits the purpose" so to speak. You can argue for both and providers do this differently, so I believe it comes down to what makes sense in your particular context.
As a general recommendation ALL meta data should be communicated in the headers. For the same reason I have upvoted the suggested answer from #adnan kamili.
However, it is not "wrong" to included some sort of meta related information such as counts or pagination in the body.
generally, I make by simple way, whatever, I create a restAPI endpoint for example "localhost/api/method/:lastIdObtained/:countDateToReturn"
with theses parameters, you can do it a simple request.
in the service, eg. .net
jsonData function(lastIdObtained,countDatetoReturn){
'... write your code as you wish..'
and into select query make a filter
select top countDatetoreturn tt.id,tt.desc
from tbANyThing tt
where id > lastIdObtained
order by id
}
In Ionic, when I scroll from bottom to top, I pass the zero value, when I get the answer, I set the value of the last id obtained, and when I slide from top to bottom, I pass the last registration id I got