The EventBrite API is great but there are a couple of really simple features that would make it much better. In particular, does anyone know a way to update the tags property of an event (or set it on a new event) - I can't see it on the API method http://developer.eventbrite.com/doc/events/event_update/ but'tags' is available in the response from get_event so am I just missing something.
If this just hasn't been exposed through event_update yet it would be fantastic to get that implemented.
Great question. Eventbrite's event data used to be organized around 'tags' -- users could tag any events for search and discovery.
This functionality was available through our web platform and the API, but has since been removed. So, no matter how users are creating new events (web or API), we've removed the ability to add tags.
The event_get method (http://developer.eventbrite.com/doc/events/event_get/) still exposes the tag information when it's available ... and for specific (less interesting) legacy reasons, there are still a fair amount of events that will continue to have this tag data, so we'll continue to support it in our read API.
If you're using the tag feature for organizing your own events, some of our users will actually put the tag information in the event descriptions as HTML comments using /event_update. This might not meet your use-case, but some people have hacked it to meet their needs.
Hope that helps!
Related
I'm a junior Rails developer and I'm trying to understand the pros/cons between CRUD web apps and REST API's.
I know how to turn a Rails Blog into an API, but I don't understand what advantages there are to doing this.
The main difference I can see is that my url for reading a blog went from this
localhost:3000/blog/1
to this
localhost:3000/api/v1/blog/1
And if I want to create a blog the url went from this
localhost:3000/blog/new
to this
localhost:3000/api/v1/blog
I made the view for the API and the Blog controller look exactly the same.
So the end result is that reading a blog or creating a blog has the exact same UX.
I feel like there is something I am not truly understanding about REST API's.
Can anyone describe a hypothetical situation where a Blog API would be better than a CRUD Blog?
I feel like there is something I am not truly understanding about REST API's.
That's not your fault; there is a lot of misunderstanding about REST API's. The Rails community in particular got confused circa 2005, and I don't know that it was ever straightened out.
localhost:3000/blog/1
localhost:3000/api/v1/blog/1
That's just a change of spelling convention. REST doesn't care what spelling conventions you use for your URI, but if you are using a framework (like Rails) to route HTTP requests to the appropriate implementation, then you want to choose spellings that make the routing easy ("convention over configuration").
localhost:3000/blog/new
localhost:3000/api/v1/blog
This change better aligns a "create" request with the caching semantics of the web. It's often the case that adding a new entry to a blog also changes the blog resource itself (the new entry gets listed in the index, for example). So after a successful create, you would like the client to stop using the old copy of the index and fetch a new one.
HTTP's cache invalidation rules describing invalidation of the target resource after a successful unsafe request, so this:
POST /api/v1/blog
instructs the client to invalidate its previously cached copies of /api/v1/blog (if the response isn't an error). Which is great, because the /api/v1/blog representation has been changed by the addition of the new blog post.
POST /blog/new
has exactly the same semantics (because "uniform interface" -- all resources understand the same messages the same way). Which means that a non error response informs general purpose clients that the /blog/new representation should be invalidated.
And that's probably not useful, because it's /blog, not /blog/new, that was changed when we added a new entry to the blog.
In general: the target-uri doesn't identify the handler of the action, it identifies the document (resources being generalizations of documents) that we are trying to change. That allows us to leverage the caching magic that is built into the web.
Here is an excerpt from an assignment I am currently doing:
Build a dummy app that:
Contains a REST API that operates over a single resource.
Contains a Backbone client that consumes that API and can list, show, create, update, and remove that resource.
My understanding was that the term "consume" implies total coverage of the API's exposed ressources. However, the assignment says "consumes that API and can [CRUD] that resource".
Is that sentence redundant or is my understanding of the term wrong?
(Bonus question: why searching Google for this question returns countless language-specific tutorials for "consuming an API" but none explain what the term actually means?).
To consume an API means to basically use any part of it from your application.
Consuming an API here means creating a client which can send requests to the API that you build.
It appears that you need to create and API which can handle Create, retrieve, update and delete (CRUD) of a resource. For instance if your REST api is to create a blog, your API should handle CRUD functions for the object/resource blogpost.
POST - Create a blog post
GET - Retrieve a blog post
PUT - Update a blog post
DELETE - Delete a blog post.
It is about the direction of the app's interaction with API - it either provides an API, or consumes it, so there are providers and consumers of API, and this is just a less general and ambiguous term than 'using'.
Simply consuming an API means using it in your application.
For, e.g., GET request to https://someapi/Users will give you all the users.
You need to request this URL https://someapi/Users to get all the users and then you can use it into your application.
I always think about Albert Einstein's quote of "If you can’t explain it to a six year old, you don’t understand it yourself." when someone asks a question that you might take for granted due to technical experience you have on a subject.
I think the following medium.com article does an excellent job explaining it: How do you explain API to a 5-year-old?
simply means : using the API.
You can do it with HTTP method (GET, POST, PUT, DELETE..) using something like Postman (Tool) or maybe you have a client app/library that calls these methods implicitly.
Lets consider the following flow to a RESTfull API:
API root
|
v
user list
|
v
user details
|
v
user messages
Suppose I have a client to consume the API, and I want to retrieve messages from a user with ID 42.
From what I've been studying, my client is not supposed to know how to "build" urls, and it should follow the links given by the API.
How should I do to retrieve messages for the user with ID 42?
The only way I can think is "walk" the whole API from it's root to user messages, which doesn't look very pretty or efficient to me.
Eg:
1 - GET / and get the link to the list of users
2 - GET /user/?id=42 and get the link to details of the user with the ID 42
3 - GET /user/42/ and get the link to user 42 list of messages
4 - GET /user/42/messages/ and finally get the user messages
Did I get something wrong? Is this the right way according to Roy's Fielding paper?
Or is it ok to just assume the messages url is "/user/{id}/messages/" and make the request directly?
Use URL templates in your API root. Let the client consume the API root at runtime. It should look for a URL template named something like "user-messages" with the value of "/user/{userid}/messages/". Then let the client substitute "42" for "{userid}" in the template and do a GET on the resulting URL. You can add as many of these URL templates you want for all of the required, often used, use cases.
The difference between this solution and a "classic" web API is the late binding of URLs: the client reads the API root with its templates at runtime - as opposed to compiling the client with the knowledge of the URL templates.
Take a look at the HAL media type for some information about URL templates: http://stateless.co/hal_specification.html
I wrote this piece here some time ago to explain the benefits of hypermedia: http://soabits.blogspot.dk/2013/12/selling-benefits-of-hypermedia.html
I believe what your real concern is should you go about implementing HATEOAS or not. Now as it's an integral part of REST specifications, it is recommended that each entity should have a link to it's child entity that it encompasses. In your case, API ROOT should show list of users with each "user" having a link (/root/users/{id}) to corresponding user's details. And each User details entity will contain a link to the list of "messages" (/root/users/{id}/messages) which, finally, inturn encompass the link to the actual message detail as well (/root/users/{id}/messages/{messageId}). This concept is extremely useful (and thus a part of the specifications) because the client doesn't need to know the url to where your entity is exposed. For example, if your users were on http://users.abc.com/rest/users/{id} but your messages were on http://messages.abc.com/rest/{userId}/messages/{messageId}, the user entity that encompasses the list of "messages" will already have link embedded to point to the right resource on a different server.
Now that being said, I haven't actually seen many REST implementations out there (I must admit I do not have TOO MUCH of an experience, but enough to give an opinion) where HATEOAS is being used widespread. In most cases the resources are almost always on the same server (environment) and the paths to resources are almost always relative to the root url.Thus, it doesn't make sense for the clients to parse out the embedded links from the object when they can generate one by themselves, especially when the client would like to provide access to a resource directly (View the message directly without getting the user entity provided you already know what the messageId is).
In the end, it all depends on how close do you want your REST implementations to that of specifications and what kind of clients are you going to have. My 2 cents would be: if you have time, implement REST with HATEOAS and feel proud about it :). There are libraries out there that will make this implementation (HATEOAS) somewhat transparent to you REST implementation (I believe spring has one, although not very mature. You can look at it here). If you are like me and don't have much time to go that route, I think you can continue with a normal REST implementation without HATEOAS and your clients will still be OK with it (or so I hope!)
Hope this helps!
I found this article about hacking urls: Avoid hackable URLs.
There is a very interesting discussion about the topic of this question in the comments section.
Question
How do we make a resource not a verb... but still maintain its special actions outside the default GET, POST, PUT, DELTE actions?
Details
I have been searching for some time now about the proper way to build a RESTful API. Tons of great information out there. Now I am actually trying to apply this to my website and have run into a few snags.
What our site does:
Our site site allows people to play games and win prizes.
The API will allow developers to build their own games and use our backend to collect, validate, store user information and give out prizes.
Scenario:
Developers will create their game then make a call to our API to let the player play the game (play_game). This play_game method combines multiple functions that we do not want a developer to run independently.
Here is what a play_game call does on the server:
It accepts player data the developer wants to store.
Validates the data (compares it to rules setup in the control panel)
Calculate what prize should be given.
Returns what prize was won to the Developer.
In addition there are multiple functions behind the scenes that get triggered like sending emails, etc.
Resource This is what our current resource looks like:
http://site.com/api/play_game
Issue:
This doesn't hold to the idea of no verbs in RESTful API's.
How do we make this resource not a verb... but still maintain its special actions outside the default GET, POST, PUT, DELTE actions?
Notes:
After asking this question I have decided to use Phil Sturgeons RESTful Framework... unless someone has a better idea.
You could place the following code into applications/routes.php
$route['(.*)'] = 'api';
Then you could access your API like:
http://site.com/play_game
BUT
You'll only have access to ONE controller only (your api controller)
Hope it helps
Is there a way to get a list of related artists through the spotify api. Like the small list that displays in the actual program?
Would be very useful if so, but I am not so sure
Cheers
Yes, it's available through libspotify. There's a SPArtistBrowse class that contains a lot of metadata, including the related artists. Check out the
CocoaLibSpotify comes with a documentation package, where you can find more details on what's included: https://github.com/spotify/cocoalibspotify.
Do note that it's currently extremely slow to load an entire SPArtistBrowse object. I'm assuming it's got something to do with libspotify loading it all in one chunk and on the main thread (?). From what I know, Spotify are suppose to remedy that in an upcoming version of libspotify, though.
Get an artist's related artists is now available through the Spotify Web API.
GET https://api.spotify.com/v1/artists/{id}/related-artists is the format.
https://api.spotify.com/v1/artists/43ZHCT0cAZBISjO8DG9PnE/related-artists is an example request.
For more information, see the API documentation.
There is also a JSFiddle demo app.
Definitely! All you need is the "artist_id" and the SpotifyPublicAPI can return a list of the related artists. You don't need an access_token at all.
You can easily test the API call here on RapidAPI. I've specifically linked you to the getArtistsRelatedArtists endpoint. Rapid will provide you with a code snippet you can copy and paste directly into your code to make the call.
Here is an example testing the API call using Beyonce's artist_id:
Here is a sample code snippet provided by RapidAPI wth Beyonce's artist_id passed as a parameter: