Is it normal that sending a request for an artist metadata, using
<OPTION>
<PARAMETER>SELECT_EXTENDED</PARAMETER>
<VALUE>LINK,COVER,REVIEW,ARTIST_BIOGRAPHY,ARTIST_IMAGE,ARTIST_OET,MOOD,TEMPO</VALUE>
</OPTION>
Returns almost non of the information (cover and artist_oet come in mind), but adding SINGLE_BEST or SINGLE_BEST_COVER will return said informations?
Are metadata limited when not searching in SINGlE_BEST mode?
Extended metadata, such as mood, tempo, artist origin and so on, will only be returned when in SINGLE_BEST or SINGLE_BEST_COVER mode.
Related
I don't see nextSyncToken in the response. I followed the doc(https://developers.google.com/calendar/api/guides/sync) and paginated using nextPageToken but I couldn't see the nextSyncToken on the last page.
API Used: GET /calendars/primary/events?maxResults=10&singleEvents=true&pageToken=********
I don't know whether if I miss anything here. Could anyone help me with this?
I have seen from the response link on the other answer comment that you are using orderBy on the request.
This is why the nextSyncToken is not showing up.
As mentioned on the documentation on Events: list -> Parameters -> syncToken:
Token obtained from the nextSyncToken field returned on the last page of results from the previous list request. It makes the result of this list request contain only entries that have changed since then. All events deleted since the previous list request will always be in the result set and it is not allowed to set showDeleted to False.
There are several query parameters that cannot be specified together with nextSyncToken to ensure consistency of the client state.
These are:
iCalUID
orderBy
privateExtendedProperty
q
sharedExtendedProperty
timeMin
timeMax
updatedMin
If the syncToken expires, the server will respond with a 410 GONE response code and the client should clear its storage and perform a full synchronization without any syncToken.
Learn more about incremental synchronization.
Optional. The default is to return all entries.
You should remove the orderBy from the request to get the syncToken
Could you please provide the response from gcalendar API? It's hard to say more without detail information. I event don't know which language are you using.
Try to use a vendor library to sort that out:
a) https://packagist.org/packages/google/apiclient (for PHP)
b) https://www.npmjs.com/package/google-calendar (for JavaScript)
and/or
Try to use alternative endpoint: GET https://www.googleapis.com/calendar/v3/calendars/calendarId/events.
The clockify API is unclear (to me) about how to iterate through results.
For example, https://clockify.github.io/clockify_api_docs/#operation--workspaces--workspaceId--timeEntries--get says
Each request is limited to 10 time entries. To get the other 10 (and the next 10 and so on), you'll have to include the page parameter and increment it with each request (eg. https://api.clockify.me/api/workspaces/{workspaceId}/timeEntries/?page=1)
Data returned from this endpoint is merely an array of timeEntries (bonus for being simple!). Reading beyond the last page returns an empty array (status=200).
So, the question is: Does clockify intend that clients read until an empty array, or am I missing something?
This is the existing behaviour I am afraid.
Hopefully, there will be "CurrentPage", "PageLength", "TotalPages" or at least "TotalRecords" in the RESPONSE body someday.
EDIT:
According to the support response their developers are working on adding TotalRecords node to let us know how many items we can expect.
The question is clear enough, but let me flesh it out with the actual example I am encountering:
In interpreting an RSS feed, there is an image specified sometimes where it is not known what kind of image it is, but it is nonetheless clear that the link type is an image, such as in this example:
<itunes:image href="http://static1.doda.com/57914/1500w/" />
That iTunes spec does not enter the image type attribute for the image. So then let's say I am taking this image link (with others) and re-syndicating it, but now as a standard ATOM link. To specify it is an image, the type attribute of the link needs to start with image (as an image MIME type), and yet what should I do about the subtype:
<link href="http://static1.doda.com/57914/1500w/" type="image" /> //??
I'm guessing MIME types can never do this, but is that the case? Can the subtype ever be left off? Another solution is not so happy either: to enter a FALSE but common subtype (e.g.: "image/jpeg").
--- update ---
Thanks to Julien for that research. So one solution just occurred to me: using a generic subtype of a given value such as: unknown, or none.
image/unknown
image/none
Maybe just go with 'unknown', but 'none' has it's benefits as well. This might be especially useful if a lot of people started using one (or both) of these values when they don't know the subtype.
I would love to hear in the comments how that idea strikes you guys, yea or nea? Good idea or bad?
Yes, in theory, the RFC4287 says:
Whatever a media type is, it contains at least one slash
atomMediaType = xsd:string { pattern = ".+/.+" }
Now, from experience, there are many feeds out there which do not include the sub-type. Be robust: if you publish a feed, make sure you include both... and if you consume feeds, be ready to handle feeds where it's missing!
Should we guard against unanticipated user input from dropdown lists? Is it plausible to expect a user to somehow modify a dropdown list to contain values that weren't originally included?
How can they do this and how can we stop it?
Absolutely check for that.
Do something like this pseudo code on the receiving end:
if { posted_value is_element_of($array_of_your_choices) }
//processing code
else {
//prompt them for good input
}
So for example: Your dropdown list is of Primary Colors they'd like their house painted. You'd have (in PHP)
$colors = array('red', 'blue', 'yellow');
if in_array($_POST['color'], $colors)
{ //process this code! dispatch the painters; }
else {echo "sorry, that's not a real color";}
Edit: This is certainly possible. If your values are being submitted via a GET request, then the user can simply enter www.example.com/?price=0 to get a free house. If it's a POST request, it may seem a little more difficult, but it's really not:
curl_setopt($ch, CURLOPT_POSTFIELDS,"price=0");
People could just use cURL to directly manipulate a POST request, in addition to a trivially large number of other clients.
A user can simply hand-write a HTTP request which has has filled in malicious data. For GET requests, for example, you may have a "State" dropdown that lists Alabama, Arkansas, etc. He may put http://example.com?state=evilstuff just simply into the browser url bar.
This is easily prevented since you already know exactly what is in the dropdown list. Simply checking to see if the input is in that list or not should be sufficient to prevent against injection-like attacks. If he puts in something other than a valid state name, throw an error.
This can only be done by modifying the HTTP response. So,
yes, it can be done and you need to safeguard against it (i.e. check if this can be a security threat and, if yes, validate the input), but
no, you don't need to bring a "nice" error message, since this cannot happen to a normal user "by accident".
When I'm bored, I edit drop-down lists in web sites just for fun. Mostly it just breaks the site, but at least once I could have gotten free or drastically reduced prices on tickets just by playing with the site's hidden fields. (Alas it was for a company I worked for, so I had to instead report the bug.)
Yes, a malicious user can submit data to your server without ever using your form, and could submit data that's not normally included in your dropdown list. This is a trivial form of attack that's often exploited in the real world.
Always check for valid input!
Some of the other answers are absolutely correct, you MUST validate on the server-side ANY data coming from the user side.
At work, we use tools such as the Firefix plug-in Tamper Data to manipulate and view data thats being posted to the server, after any client-side (javascript) validation has been done. Also, you can even use simple tools such as Firebug to visibly alter drop-down boxes to contain values that weren't put there by the server before submitting it.
The closest thing I could find was System.Net.Mime.MediaTypeNames but that doesn't seem to have everything (like json) since it seems to be more focused around email attachments.
An enum doesn't make much sense. MIME types are open-ended. That is, the list is not finite: new types are added from time to time.
See RFC4288: Media Type Specifications and Registration Procedures
In 2022, with .NET Core and .NET5+, this is now available via MediaTypeNames. For example:
MediaTypeNames.Application.Json
MediaTypeNames.Image.Png
MediaTypeNames.Text.Html
Microsoft documentation around MediaTypeNames, and each of Application, Image, Text.
https://learn.microsoft.com/en-us/dotnet/api/system.net.mime.mediatypenames?view=net-6.0
https://learn.microsoft.com/en-us/dotnet/api/system.net.mime.mediatypenames.application?view=net-6.0
https://learn.microsoft.com/en-us/dotnet/api/system.net.mime.mediatypenames.image?view=net-6.0
https://learn.microsoft.com/en-us/dotnet/api/system.net.mime.mediatypenames?view=net-6.0
https://learn.microsoft.com/en-us/dotnet/api/system.net.mime.mediatypenames.text?view=net-6.0
IANA's database is most likely to be complete. Currently, they have the list available in CSV format at https://www.iana.org/assignments/media-types/application.csv. I am assuming this is a stable URL whose content changes as updates are made. If you want to stay up to date, you'd need to put together a mechanism that is appropriate for your needs.
There is also the mime.types file that comes with Apache which seems to have been derived from the said list.
If like me you wanted to have no hard-coded string in your code you can use something like below
httpHeaders.add(HttpHeaders.CONTENT_TYPE,MediaType.APPLICATION_JSON_VALUE);
which is essentially
httpHeaders.add("Content-Type","application/json");