I'm designing an api that returns an image url that gets from a third party service.
My problem is that for all the media I'm using what I call a "media object"
{
"ContentType": "image/jpeg",
"href": "http://..."
}
But the third party service does not provide a content type, just a url.
Is the image/* ContentType valid?
I saw it mentioned in other questions like this and this, but I haven't seen it in any Standard like the rfc2045 and its not in the list of options in Wikipedia.
My intention is to prevent my server from having to load the image in order to get the real content type.
The reason I'm using the "media object" is because we can server videos in the same field and that information is very useful to play videos and to separate images form videos.
Technically speaking, no.
image/* is only valid as a pattern for MIME types, not as a MIME type on its own. (For instance, in HTTP Accept headers, image/* can be used to accept any image file.) Since it sounds like you're making up your own protocol here, though, it's up to you whether this is allowable; just don't return it as a Content-Type for an object.
Anyways, you may also want to consider running a HEAD request on the URL and getting the real content type from that.
Related
I have been working on designing an API that lets client create a product (think of product as something like website domain, something that comes into existence when client makes order for it to the service). Correspondingly with every purchase results in creation of the order object. Which means creation of two resources via a single POST request.
So afaik, the RFC standards recommends sending 201 on resource creation with URI for the resource in the Location header. But in the above scenario, we are creating two resources, domains and orders and I would want response to contain information related to both the resources.
Response would look something similar to this
POST /domains/
Request
body: {"domain_name": "awesome.com"},
Response
Body: {"order_id": "1234"}
Headers:
Location: http://example.com/awesome.com
But does not look very RESTful. I was wondering if there was a RESTful way to do this?
RFC 7231, section 6.3.2
The 201 (Created) status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. The primary resource created by the request is identified by either a Location header field in the response or, if no Location field is received, by the effective request URI.
The 201 response payload typically describes and links to the resource(s) created.
In other words, on the web we would solve your riddle by returning an HTML document that includes hyperlinks to all of the created resources, along with text to describe each, so that the client would know which new identifiers are available.
To make such a response machine readable, we would do the work of documenting the schema of the message, so that specialized clients would know how to identify the semantics of each of the provided links.
The same idea works if you replace HTML with a different media type (for example application/json). You define the schema, and then specialized clients can parse the response to find the identifiers that they need.
Of course, REST is largely about standardizing things so that we can use general purpose components; application/json is somewhat inadequate here, as it doesn't include a URI type (just strings, which are too general). So to be more "RESTful", you would choose one of the specialized JSON types that has a general purpose representation of a link.
Sookocheff's article On Choosing a Hypermedia Type.... is a decent starting point for the kinds of questions you will want to be considering.
For example, when you perform an call from summary api of wikipedia, there is this header in the request
accept:application/json; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/Summary/1.3.7"
What is the purpose of this particular bit. I would like to understand since the value changes when you, for example, use the VisualEditor or access the api with different mean.
profile="https://www.mediawiki.org/wiki/Specs/Summary/1.3.7"
This specifies the response format and provides convenient access to a human-readable documentation.
The URL in your header leads to nowhere, but https://www.mediawiki.org/wiki/Specs/Summary/1.3.0 does exist and is probably valid for 1.3.7 as well.
I'm designing a list endpoint for a resource that merits both full and light version of the resource called /transactions. By default, the response will include the complete resource, but there is also a need to provide clients with the "simplified" version of the resource list.
The first option is to use a custom param (e.g. /transactions?summary=true)
The second option is to use a custom endpoint, though not very RESTful (e.g. /transactions/summary)
The third option is to use content-type to allow a client to declare the alternative response body format. How would this look? (application/json+summary)? Are there any good examples of this being done?
Any other options come to mind?
The third option of using the Accept/Content-Type headers allows the media types to be a representation of a data, separate from the data itself.
A good example of this is github's API: https://developer.github.com/v3/media/
Which uses the http headers to allow clients to choose the format of the data, as well as the version. So in your case, the request could look something like:
curl http://api.host.com/transactions -H "Accept: application/summary+json"
And the response would contain a body of your simplified data format and the Content-Type header set to application/summary+json
If you want to be more pedantic about it, you could also use a vendor media type as application/vnd.yourcompany.summary+json. In this case, vnd implies that the media type is a vendor typically associated with application specific media types.
More Info:
Collection+JSON
A similar answer
A bit from restful API design
Does anybody know how to allow multiple content types in an Amazon S3 upload policy when uploading using HTTP POST? I can't seem to find the answer to this anywhere.
I am aware that I can restrict an upload to any file with a MIME type that starts with "image/" as follows:
{"expiration": "2015-02-28T00:00:00Z",
"conditions": [
["starts-with", "$Content-Type", "image/*"]
]
}
But how would I go about allowing only a certain few MIME types which might not all start with the same characters?
This isn't supported. It's either a single pattern match (including a wildcard), or you have to allow all.
Depending on how the form is being generated -- dynamically, one assumes -- you might be able to simply tell the application the content-type of the file you intend to upload when requesting the resource that builds the form, hence, telling the application what content-type value to use on the form and when generating the policy document.
If the application doesn't find that content-type in its list of acceptable values, it could just refuse to render the form, and refuse to create and sign a matching policy statement.
Depending on the application, there may be little point in worrying too much about the Content-Type field here, because this is not actually restricting the content-types that can be uploaded... it's only restricting the value passed in the value parameter of input type="input" name="Content-Type". That's all this actually restricts.
There's no validation being performed as to whether that value accurately represents the MIME type of the payload that is being updated, so the policy document isn't restricting what kind of content you can upload. It's only restricting what kind of content you can claim you are uploading.
It may also be more appropriate to just accept otherwise-unusable uploads and handle the problem on the back-end, after the fact.
I have a DESKTOP application which interacts with a web service through their RESTful api and OAuth 1.0. I can use all the resources fine, authentication, get/post calls to retrieve and send simple text data etc, no problems there.
However, I'm struggling to send binary data. The service allows sending pictures. For one part, they have a non-OAuth api through which you can also send a file in plain binary, simply pass some params in the URL and put the entire binary file in the post.
Now to do this through the OAuth api, becomes an issue:
The service specifies the post needs 2 parameters (not to be included in the URL since this is REST, but in the POST parameters):
image A binary file, base64 data, or a URL
type The type of file that's being sent in. Accepted values: file, base64, url
So we have 2 parameters: image contains the file itself, and type would be "file" to specify binary. But how am I supposed to include this through OAuth? given that the -image- and -type- parameters (and their values) must be used to generate the base string for the signature, which is matched against the parameters included in the POST.. I can't include the entire binary there as a value for the image parameter; so how is it done in this case?
nvm, their OAuth api expects the file as multipart/form-data with the variables there, and none in the base string for the signature (their non-OAuth api instead doesn't need multipart, so I expected their OAuth wouldn't either; their documentation is a bit lacking in this area).