Is it possible to access the 120x120 image of the Social Tables venue/bookable room through the API (same image that's displayed in the Venues area of the app)?
I can see urls for images in the response from the Rooms API endpoint, but they present a 'key does not exist' error when accessed. Not sure if these are intended for use by API consumers or not.
{
"id": "cj1i5gi2h05f10fgc0wi6vuwc",
...
"resources": {
"svgs": {
"room": "https://s3.amazonaws.com/socialtables-property-service/rooms/cj1i5gi2h05f10fgc0wi6vuwc.svg",
"withFloor": "https://s3.amazonaws.com/socialtables-property-service/rooms/cj1i5gi2h05f10fgc0wi6vuwc-with-floor.svg"
},
"images": {
"room": "https://s3.amazonaws.com/socialtables-property-service/rooms/cj1i5gi2h05f10fgc0wi6vuwc.png",
"160x160": "https://s3.amazonaws.com/socialtables-property-service/rooms/cj1i5gi2h05f10fgc0wi6vuwc-160x160.png",
"withFloor": "https://s3.amazonaws.com/socialtables-property-service/rooms/cj1i5gi2h05f10fgc0wi6vuwc-with-floor-1200x1200.png"
}
}
}
It is definitely possible - the current behavior relates to platform lag on our end.
The images are created asynchronously and eventually uploaded to the URLs indicated on the 4.0/rooms/:room_id endpoint. Unfortunately, this sometimes means that the image is not yet present in the S3 bucket at request time. We recommend that API consumers poll for the image after creating a new room.
It also appears that we are experiencing significant delays generating the images at this time. We appreciate you bringing the issue to our attention, and are working to churn through the queued image backlog.
Related
I'm trying to upload an image as profile picture using WhatsApp Cloud API *.
After creating an application using WhatsApp Cloud API I'm not allowed to access neither using the regular application nor using Business Application. It says something like "try again in one hour". So I have to implement everything using the API.
After reading the docs and importing Postman Endpoints I found the one called Business Profiles > Update Business Profile
https://graph.facebook.com/{{Version}}/{{Phone-Number-ID}}/whatsapp_business_profile
It has a field "profile_picture_url"and I have tried POSTing media https://graph.facebook.com/{{Version}}/{{Phone-Number-ID}}/media and then with the given ID y used https://graph.facebook.com/{{Version}}/{{Media-ID}} to get the URL but it didn't work. The rest of the information is updated successfully
{
"messaging_product": "whatsapp",
"address": "",
"description": "Simple Bot",
"email": "...#gmail.com",
"websites": [
"https://..."
],
"profile_picture_url": "https://lookaside.fbsbx.com/..."
}
However if I try to send someone using the ID and the endpoint https://graph.facebook.com/{{Version}}/{{Phone-Number-ID}}/messages it works fine.
And if I use Download Media Content with the URL in Postman it works fine too.
I don't know if I have misunderstood something or if it can't be done using the API.
It is mentioned in the Cloud API Documentation:
profile_picture_url (Optional): URL of the profile picture generated from a call to the Resumable Upload API.
But, i got it working using profile_picture_handle instead of profile_picture_url. So how do we get the profile_picture_handle?
Prerequisite:
Graph API token here. Or use your WhatsApp Cloud API token.
App ID, go Apps > Your App > Settings (sidebar menu) > Basic
Update Photo Profile:
Call POST https://graph.facebook.com/v14.0/{{appId}}/uploads?access_token={{token}}&file_length={{fileSizeInByte}}&file_type=image/jpeg
Save the session id you got, upload:XXXXXX?sig=XXXXXX.
Call POST https://graph.facebook.com/v14.0/{{sessionId}}, with the headers: Authorization=OAuth {{token}}, file_offset=0, Host=graph.facebook.com, Connection=close, Content-Type=multipart/form-data, and include your image file in the request body with type binary. If you using Postman, see image below (This is what I missed for hours).
Save the handle result you got, 4::XXX==:XXXXXX.
Finally, call POST https://graph.facebook.com/{{Version}}/{{Phone-Number-ID}}/whatsapp_business_profile, with json request body: {"messaging_product": "whatsapp", "profile_picture_handle": "4::XXX==:XXXXXX"}
That's it, You can check the profile picture.
The last step you have to add your taken by selecting "Bearer" or else it will give you error. I had hard time on the last ones, do all the steps and then go to the following link and it should help.
https://web.postman.co/workspace/My-Workspace~a4ddb3b8-02a3-4132-8384-66e63e149b7b/request/22958165-506a0542-c845-41ac-b3fb-b8209fd6f53b
I was wondering if accessing data, For example view any item, modify any item in Db/Firestore directly via Firebase console adds to usage (data download/ FireStore Read etc.)
I googled it to find an answer but I didn't find any. So raising my query here.
Also wanted to know if there is a way to provide write access to a particular child to 3-4 specific emails (google authentication). I understand we can allow writing to users who created it using the below rules. But in my case, I want others (few) also to be able to write to the child but not all( so cannot use ".write": "auth != null" )
{
"rules": {
"users": {
"$uid": {
".write": "$uid === auth.uid"
}
}
}
}
Thanks in advance.
Yes, it does charge you. The documentation says,
Firebase console data: Although this isn't usually a significant portion of Realtime Database costs, Firebase charges for data that you read and write from the Firebase console.
Similarly you are charged for any reads and writes from the Firestore console. Also you need to be the project owner (or have editor/viewer role) to access the console. You'll be charged the amount of data loaded or written. For example, if the console loads 500 documents then you'll be charged 500 reads.
For the data retrieved from client side, "Firebase charges for the downloaded data. Typically, this makes up the bulk of your bandwidth costs, but it isn't the only factor in your bill." Make sure you check all the factors in the documentation above.
To allow specific users to read or write to your database, you can try using custom claims. You can refer to this answer for a detailed explanation on security rules with custom claims.
I'm trying to upload a .glb file to a product in a Shopify store through Shopify GraphQL Admin API. For that, it first returns a google cloud storage signed URL, to where I should upload my file through an HTTP PUT request. After uploading, I should attach the same URL to the product with another API call.
This question is about that file uploading to the cloud storage signed URL. I include all these details to make this question easy to be getting answered. So, please read till the end.
What data Shopify provides me with is mentioned below.
{
"data": {
"stagedUploadsCreate": {
"stagedTargets": [
{
"parameters": [
{
"name": "GoogleAccessId",
"value": "threed-model-service--6bgx7cbe#shopify-applications.iam.gserviceaccount.com"
},
{
"name": "key",
"value": "models/a6436c066064bac3/windmill.glb"
},
{
"name": "policy",
"value": "eyJleHBpcmF0aW9uIjoiMjAyMC0wNy0yMVQwOToxNjoxMFoiLCJjb25kaXRpb25zIjpbWyJlcSIsIiRidWNrZXQiLCJ0aHJlZWQtbW9kZWxzLXByb2R1Y3Rpb24iXSxbImVxIiwiJGtleSIsIm1vZGVscy9hNjQzNmMwNjYwNjRiYWMzL3dpbmRtaWxsLmdsYiJdLFsiY29udGVudC1sZW5ndGgtcmFuZ2UiLDE5NzE3MiwxOTcxNzJdXX0="
},
{
"name": "signature",
"value": "vz+OdcEmD9Kbv2FbXdxWNUk59XO2GmXzhvtDswXbDQNcyZpUufI85z5x2PFGv/XZ+tSBsl/S393pmy0Bu9xG7oVgOZcMIWEbOIm9kXgQunbjKQY3Ff3BBpMocB0xazzlYmckZozdJ8ZZkyox/c/gEe1QaxqW4+419iufuFHy4Bp3LL/aUr+ATNChwn9Dn8+XnHMOckZxDlbiggcF3dx+yBuTFia8FneaVSiU0M5DIWmHqHb2YDCV0KtEP6jfTj/PQVUjS8pn8EGhrRaMx7Q2A5G8Pycgc9H35hqJnnUKCTa3AYeyI45RbhddYnIWw9YrAADXuQYlVCo6LYBHjxsCWA=="
}
],
"resourceUrl": "https://storage.googleapis.com/threed-models-production/models/a6436c066064bac3/windmill.glb?external_model3d_id=bW9kZWwzZC00MDg5Ng==",
"url": "https://storage.googleapis.com/threed-models-production/models/a6436c066064bac3/windmill.glb?external_model3d_id=bW9kZWwzZC00MDg5Ng=="
}
],
"userErrors": []
}
}
}
Using these parameters, I construct a signed URL as follows.
resourceUrl+"&signature="+signature+"&key="+key+"&policy="+policy+"&GoogleAccessId="+GoogleAccessId
Eg:
https://storage.googleapis.com/threed-models-production/models/a6436c066064bac3/windmill.glb?external_model3d_id=bW9kZWwzZC00MDg5Ng==&signature=vz+OdcEmD9Kbv2FbXdxWNUk59XO2GmXzhvtDswXbDQNcyZpUufI85z5x2PFGv/XZ+tSBsl/S393pmy0Bu9xG7oVgOZcMIWEbOIm9kXgQunbjKQY3Ff3BBpMocB0xazzlYmckZozdJ8ZZkyox/c/gEe1QaxqW4+419iufuFHy4Bp3LL/aUr+ATNChwn9Dn8+XnHMOckZxDlbiggcF3dx+yBuTFia8FneaVSiU0M5DIWmHqHb2YDCV0KtEP6jfTj/PQVUjS8pn8EGhrRaMx7Q2A5G8Pycgc9H35hqJnnUKCTa3AYeyI45RbhddYnIWw9YrAADXuQYlVCo6LYBHjxsCWA==&key=models/a6436c066064bac3/windmill.glb&policy=eyJleHBpcmF0aW9uIjoiMjAyMC0wNy0yMVQwOToxNjoxMFoiLCJjb25kaXRpb25zIjpbWyJlcSIsIiRidWNrZXQiLCJ0aHJlZWQtbW9kZWxzLXByb2R1Y3Rpb24iXSxbImVxIiwiJGtleSIsIm1vZGVscy9hNjQzNmMwNjYwNjRiYWMzL3dpbmRtaWxsLmdsYiJdLFsiY29udGVudC1sZW5ndGgtcmFuZ2UiLDE5NzE3MiwxOTcxNzJdXX0=&GoogleAccessId=threed-model-service--6bgx7cbe#shopify-applications.iam.gserviceaccount.com
Then I try to make a PUT request to this URL with the .glb file in POSTman as shown in this image -->
with the following headers.
But I don't get a success response. In fact, I get a 400 error with the following message.
<?xml version='1.0' encoding='UTF-8'?>
<Error>
<Code>MalformedSecurityHeader</Code>
<Message>Your request has a malformed header.</Message>
<ParameterName>signature</ParameterName>
<Details>Signature was not base64 encoded</Details>
</Error>
Can someone point me out what I'm doing wrong here? I have been dealing with this error for days and read a lot of questions and articles, but couldn't get this to work. Therefore, any helpful suggestion is highly appreciated.
Few suggestions for you to try:
When generating the initial request (Shopify did this in this case), GCS usually includes HTTP headers of that request and includes them in the request signature and expects the upload request (the one you're trying to do) to match same HTTP header values.
This means you are advised to include only those headers Shopify specified in their request in your signed key upload request and nothing extra. So first try removing all HTTP headers that are not documented by Shopify (e.g. ones added by POSTMAN) and ensure all headers values follow Shopify docs (e.g. Content-Type should match)
You need to ensure signature parameters are in the expected names and formats:
signature value field is named: x-goog-signature and not signature (This is the likely reason for the error you're getting that GCS can't find the expected param)
you likely have to provide a signing algorithm key as well (x-goog-algorithm)
you might need other keys as well depending on other factors like authentication and so
I'd say these should be documented by Shopify SDK and/or examples
One suggestion to simplify/speed up things for you might be to use Google Cloud Utils (gsutil command line tool) to create a signed url request and then try to reproduce the same behaviour in your code
For more information see these links:
https://cloud.google.com/storage/docs/access-control/signed-urls
https://cloud.google.com/storage/docs/access-control/signing-urls-with-helpers#gsutil
Then after familiazing yourself with signed url format, you can check this for some sample code on how to do in your own code:
https://cloud.google.com/storage/docs/access-control/signing-urls-manually
For your reference when reading the docs, the type of Signed URL you're trying to create is non-resumable upload (which uses a single PUT request) rather than resumable (which uses an initial POST plus a series of PUTs)
Sorry I haven't worked with Shopify but the above is from my experience working with GCS signed urls
im building a specific book reader like app.
Main page call api/booksList and receive the json array containing each book info like:
[ { id: server_db_id, title: "title test", sum: 10 , date: ... }
]
ans its cached after the request, so im not saving the book list into indexedDB, localStorage or other storage. If i need one specific book, i just call the api book list again and filter it. Is that bad design? (book will be over 200 items)
Whe user open the book, it call the /api/book/book_id and its cached too, the opened book response is a json list of the lines of the book, eg:
[
{
id: ...
content: "This is line...lore ipsum..."
....
}
]
I put the api response inside vue data variable and the component is rendered correclty
Im not using any kind of handler for keeping this offline by my hand. To detect if user already opened this book, i just call the api, check if errors happened or the responde body has content.
Is that a wrong, bad or stupid decision? Will this hit the quota limit api or other kind of limitation? The "gods" of pwa will raise the finger to me and say: WAAAT. (im not using indexedDB at first because it need some models handling and i want to make things easier if possible)
I my self was just researching this and concluded, at the moment I am going to go with this method, where I use cache for assets, js, css, html etc based on their matching routes.
Then when it comes to data e.g. json requests etc. Its best to store them in indexedDB (or an equivalent), which really does not require a model or schema as such.
See Jake Archibald's IndexedDB-Promise library https://github.com/jakearchibald/idb its really simple to get your head round.
Though both Jake and Addy say it's not a defacto rule, so you can decide ultimately what is best for you.
Read this for better clarification
https://developers.google.com/web/ilt/pwa/live-data-in-the-service-worker
https://medium.com/dev-channel/offline-storage-for-progressive-web-apps-70d52695513c
It helped me to make a better decision on how to go about moving forward.
Recommendations Also
Check out PWA Training: https://developers.google.com/web/ilt/pwa
Workbox: https://developers.google.com/web/tools/workbox (This has sped up my development massively!)
Codelabs: https://codelabs.developers.google.com/ (Search PWA)
The guides on here are really good at taking you through everything you need.
Good Luck with your PWA
Random thought (edit)
One thing that makes me question this though is based on some of the examples and guides I have seen is that, data storage is handled in a more ad-hoc manner. For example, if the PWA calls out an API, there are two methods I have come across where you can either manage cached data in the application or in the service worker, e.g. if your API calls to get JSON fails in the app, it can revert to getting data in the indexedDB which hopefully was pre-cached the first time your app called the API.
Or you can use self.addEventListener('fetch', (event) => { ad-hoc stuff here }) this is where you can match either an asset, or data request and hijack the response with either a cache or indexedDB response. Which prevents the need handle offline data in your app.
The first method makes me feel uneasy so i'm gonna go with the addEventListener approach both in the service worker cause thats what it is there for plus my app does not then have to worry about that.
Let's assume that I have a resource called group with the following representation:
{
"id": 1,
"name": "Superheroes"
"_links": {
"self": {
"href": "http://my.api.com/groups/1"
}
}
}
Now let's say I want to create a new person instance by POSTing to /persons/1. Which of the following should I use for the request body:
Using ID
{
"name": "Batman",
"groupId": 1
}
Using link
{
"name": "Batman",
"group": "http://my.api.com/groups/1"
}
With the first method I access the id directly either to look up the related resource or eventually store the id in the database, when I persist the person instance. But with the other method, I either have to extract the id from the URI or, follow the link to load the related resource, and then find out its id. I really don't want to store the URI in the database.
With the latter option, seeing that the server controls the structure of the URI, is it fine for me to parse the id out of the link? Following the link back to the server itself seems odd, seeing that at this point we already have access to the information directly (we just need the id).
So to sum up, which of these options is best?
Use the id directly.
Use the link, but parse out the id.
Use the link, but access the link to get the resource instance, and then get the id.
TL;DR: Use simple ids.
More detailed explanation:
A straightforward approach is to create a person by POSTing to /groups/1/persons with a payload {"name": "Batman"}.
However, while such approach works for simple cases, the situation gets complicated if there are 2 resources that need to be referenced. Let's assume that a person also needs to belong to exactly one company:
GET /persons/1
{
"name": "Batman",
"group": 1, // Superheros, available at /groups/1
"company": 5 // Wayne Enterprises, available at /companies/5
}
Since there is no relationship between companies and groups, it is not semantically correct to create a person via POSTing to /groups/1/companies/5/persons or to /companies/5/groups/1/persons.
So let's assume you want to create a person with a request looking like this:
POST /persons
{
"name": "Batman"
"group": ???, // <--- What to put here?
"company": ??? // <--- What to put here?
}
Which brings us to the answer to your question:
Ease of use. Your API should be primarily designed for the ease of use. This is especially true, if you design a public API. Therefore, Option 2 (Use the link, but parse out the id) is out, since it imposes additional work for clients of your API.
Constructing search queries. If you want to be able to query persons which belong to the company 10 and the group 42, simple ids lead to more readable and less error-prone urls. Which of the following do you consider more readable?
URL with a simple id:
GET /groups/42?company=10
or URL with a url-encoded link:
GET /groups/42?company=http%3A%2F%2Fmy.api.com%2Fcompanies%2F10
I wouldn't underestimate the point of readability. How many times do you need to debug your API in various curls, logs, postmans, etc.
Development Links need to be parsed in the backend, while simple ids can be used directly. It's not about performance, but rather about additional work/tests you have to put in.
Endpoint maintenance. Imagine that your API endpoint evolves. You decide one day to switch to https or to include versioning in the url. This might break API clients, if they for some reason rely on structure of the links. Also, you might want to checkout if link parsing on your backend is done properly.
Argumentum ab auctoritate I know this is not a proper argument, but if you checkout APIs of large players, e.g. Twitter, Github or Stripe, they all use simple ids.
HATEOAS. One common argument in favour of links is that it is aligned with HATEOAS. However, as far as I know, this relates to additional links in API responses rather than using links in payloads of POST requests.
All in all, I would go for simple ids, since I haven't yet heard a compelling argument favouring links, which would beat the aforementioned.
You are missing two important things here.
You need a standard way to describe forms in the response, in this case your POST form.
The information about the group ids / uris, or how to get them has to be described in the form in a standard way.
For example a HTML FORM with a SELECT INPUT would be RESTful. The closest thing we got in json to do the same is json-ld and hydra. But if you are obsessed with hal, then use hyperagent forms or something like that. It will never be a standard, but if compatibility is not an issue, then it is good enough.
To answer your question, you should use the id, because the server knows how to interpret it. The client needs the resource identifiers, the server needs it only in the uri part of the request, not in the body.
From my experience, it is always best to go with the simplest solution for making requests.
The process of generating a new url and parsing it seems excessive to get a resource, whereas sending the id of the item you want seems much simpler.
Thus, I would send a request in the form:
{
"name": "Batman",
"group": 1
}