I see either link them directly or visual attribute them. Example: say my website provides a recommendation directly to a user based on their submitted interest, do I just make sure "powered by Foursquare" shows underneath?
Any help would be appreciated! I'm new to tech development
These policies are generally more vague on purpose. Rule of thumb: If you're showing any data to users that isn't your own, it should be clear to them where it's coming from. This is done so the data provider gets proper attribution but also can protect yourself against content being displayed on in your app/site.
For Foursquare specifically, it seems like you would need to include a "Powered by Foursquare" icon and optionally provide a link to the venue if the user may need more information about the place.
Related
I am reviewing Piranha CMS and really like the framework.
I am wondering how I can associate permissions to Regions and Media elements.
I was thinking that this may be easily accomplished through a custom extension but would like to know if this is the recommended approach.
What I'd like to do is to restrict rendering of a region if the current user's does not have access to it. I was thinking I may be able to add a group GUID as the permission property of the region extension. If the permission property is an empty GUID then it will render the region otherwise the current user must be a member of the group that the region is associated to.
I would like to do the same for Media elements.
Cheers
John
You could solve both the region & media question with a custom extension, however I'm not really sure I follow why you would need it for the page region.
As regions are merely considered a "part of a page" there's no way to customize security for a single regions, it is set on the complete page.
As media is usually rendered in some context, as a page, there's currently no security setting for uploaded media. This however is a feature that could be added into the core framework as it could make sense for some use-cases.
Best regards
Håkan
A quick api uri design question. We have resources that belong to our clients. These resources can be edited / viewed / deleted by the client who entered them into our system. The resources can be searched by all clients but access is only granted if certain criteria is met (client has level 3 access etc).
Choice 1: include the client who owns the resource in the uri.
client/:clientname/widgets
client/:clientname/widgets/:id
Choice 2: ditch the whole "client/:clientname" since this part of the uri has to be verified and checked against the credentials of the user accessing the information.
/widgets
/widgets:id
We have other resources other than widgets that also belong to clients.
Which way is the more preferred way and why? Cheers.
The only advantage that Choice 1 gives it that it allows you to effectively namespace widgets/whatever by the user that uploaded them. Similar to Github, how different users can have projects with the same name. If Github were to exclude the username, no two users could have a project with the same name. If the widgets are all unique, I would go with option two and you will have a 1:1 mapping from a widget the the user that created it, thus supplying it is just extra work for whoever is calling it.
If you can have the same widget name for different users, use an approach which includes the username. You may not need to actually use the 'client' word in your url though; using a path like '/:clientname/widget/:widgetid' instead.
Note that this is kind of an opinion based question, so you may get different answers. You'll have to weigh the information provided and in the end make your own decision.
I recently heard term 'Writable API' which is totally new for me. Can anyone explain what does it mean?
A publicly writable API is an API that allows anyone to attach meta-data to objects in the owner's database without changing the original content.
For example, take this object: http://twitter.com/#!/MarsPhoenix/status/1917793215. It is a tweet from the Pheonix Mars Lander.
The tweet is owned by Twitter. But what if I want to tag it and share those tags with the world?
If Twitter opened a writeble API, I could add my own data to this tweet. Say I add the tags "mars" and "nasa" to this object, they would be stored as devon/tag:mars and devon/tag:nasa in their database. If user Bob added a tag of "phoenix", it would be stored as bob/tag:phoenix in Twitter's database.
Now we can both share our tags with the world without overwriting any of Twitter's or each other's data.
Here is a good blog post explaining the concept:
http://blogs.fluidinfo.com/fluidinfo/2011/02/14/what-is-a-writable-api/
I wrote the article #Devon linked to, so agree with him :-) Though I'd change his "without changing the original content" to also say that the addition to the data also doesn't require the permission of the original app either (APIs are in a way largely about permission - they're designed to let you do things, but also sharply limit what you can do).
As a concrete illustration of #Devon's example of putting metadata onto tweets, here's how you can do it with Fluidinfo: http://blogs.fluidinfo.com/fluidinfo/2009/12/01/putting-metadata-onto-tweets-with-fluiddb/
We've also posted some writable API examples, for Boing Boing and Union Square Ventures. See http://blogs.fluidinfo.com/fluidinfo/2011/01/27/how-we-made-an-api-for-boingboing-in-an-evening/ and http://blogs.fluidinfo.com/fluidinfo/2011/02/15/how-i-made-a-writable-api-for-union-square-ventures-in-an-hour/
We have a couple more nice examples coming out this week at the LAUNCH conference in SF.
Hope that helps!
Terry Jones
A Writable API would be an API that allows you to write data to the target system/platform rather than a Read-Only API.
For example, StackOverflow/StackExchange provides a Read-Only API whereas the Twitter API is Writable.
I would like to be able to generate custom bit.lys (http://bit.ly/thecakeisalie type things) through their API. This does not appear to be possible, but I thought I'd check; does anyone happen to know otherwise?
This unfortunately had to be removed for our free users due to on-going abuse. All of the custom bitlinks on bit.ly are created in the same key space, so allowing for automated creation there quickly leads to there being no sane options availble for anybody else.
That being said, we have recently added the ability for our paid customers to create custom bitlinks if they are using a custom domain. In this case, our customers get their own key space so creating custom bitlinks en-mass isn't a problem.
It was removed from the API. I like many others were trying to do this and bit.ly's support email replied saying it has been removed. Similar experiences on their ApiDocumentation wiki here.
I'm a new REST convert and I'm trying to design my first RESTful (hopefully) api and here is my question about addressing resources
Some notes first:
The data described here are 3d render
jobs
A user (graphics company) has multiple projects.
A project has multiple render jobs.
A render job has multiple frames.
There is a hierarchy enforced in the data (1 render job
belongs to one project, to one user)
How's this for naming my resourses...?
https:/api.myrenderjobsite.com/
/users/graphicscompany/projects
/users/graphicscompany/projects/112233
/users/graphicscompany/projects/112233/renders/
/users/graphicscompany/projects/112233/renders/889900
/users/graphicscompany/projects/112233/renders/889900/frames/0004
OR a shortened address for renders?
/users/graphicscompany/renders/889900
/users/graphicscompany/renders/889900/frames/0004
OR should I shorten (even more) the address if possible, omitting the user when not needed...?
/projects/112233/
/renders/889900/
/renders/889900/frames/0004
THANK YOU!
Instead of thinking about your api in terms of URLs, try thinking of it more like pages and links
between those pages.
Consider the following:
Will it be reasonable to create a resource for users? Do you have 10, 20 or 50 users? Or do you have 10,000 users? If it is the latter then obviously creating a single resource that represents all users is probably not going too work to well when you do a GET on it.
Is the list of Users a reasonable root url? i.e. The entry point into your service. Should the list of projects that belong to a GraphicsCompany be a separate resource, or should it just be embedded into the Graphics Company resource? You can ask the same question of each of the 1-to-many relationships that exist. Even if you do decide to merge the list of projects into the GraphicsCompany resource, you may still want a distinct resource to exist simple for the purpose of being able to POST to it in order to create a new project for that company.
Using this approach you should be able get a good idea of most of the resources in your API and how they are connected without having to worry about what your URLs look like. In fact if you do the design right, then any client application you right will not need to know anything about the URLs that you create. The only part of the system that cares what the URL looks like is your server, so that it can dispatch the request to the right controller.
The other significant question you need to ask yourself is what media type are you going to use for these resources. How many different clients will need to access these resources? Are you writing the clients, or is someone else? Should you attempt to reuse an existing standard like XHTML and classes/microformats? Could you squeeze most of the information into Atom? Maybe Atom with some extra namespaces like GDATA does it? Or is this only going to be used internally so you can just create your own media types, like application/vnd.YourCompany.Project+xml, application/vnd.YourCompany.Render+xml, etc.
There are many things to think about when designing a REST api, don't get hung up on what your URLs look like and you should really try to avoid doing "design by URL".
Presuming that you authenticate to the service, I would use the 1st option, but remove the user, particularly if the user is the currently logged in user.
If user actually represents something else (like client), I would include it, but not if it simply designates the currently logged in user. Agree with StaxMan, though, don't worry too much about squeezing the paths, as readability is key in RESTful APIs.
Personally I would not try to squeeze path too much, that is, some amount of redundant information is helpful both to quickly see what resource is, and for future expansion.
Generally users won't be typing paths anyway, so verbosity is not all that bad.