Tag: api

Posted on

How to Make Requests to Yelp’s API v3 (Fusion)

I recently worked on updating an app I made a couple of years ago, that was using Yelp’s API. I was running into some issues deploying the older version of the app to Heroku, so I decided to update the API it was using to the latest version for Yelp, v3.

As I’m writing this, I found that the Yelp API documentation was a little confusing. The older API required a consumer key, consumer secret, token, and token secret. The Yelp Fusion API only requires an Authorization parameter.

Authentication for the Yelp API is outlined here, although I had to do a bit of fiddling around until I was able to successfully make an API GET request. Here’s what Postman looked like once I was able to make a successful call (click the image to see a larger view):

Something I wasn’t aware of from the APIs I’ve worked with, is that the Headers required a Content-Type with the value application/json and an Authorization with a value that started with the word Bearer, a space, and then the API key I had received from Yelp. So the value looked something like Bearer 203498lksjsdlkfej9if

If you’re curious about how I wrote the code for my application, you can take a look at my github repo for the app, What am I Even Doing?

Posted on

RESTful Web API Design

An API is a set of routines or functions. It’s an interface used for performing tasks, retrieving data, and manipulating data. APIs use HTTP methods, which are used on a resource to GET, POST (submit form data), PUT (for updating files), PATCH (a partial update), and DELETE.

Adding an API

  • Bolt-on strategy – when you already have an application and are adding an API to it
  • Greenfield strategy – no underlining application. There’s complete freedom and flexibility to do what you want. Generally the “API first” or “mobile first” mentality.
  • Facade strategy – wraps existing logic with replace as you go. This is ideal for legacy systems so the application is always functional.

Designing the Relationship

  • Independent – the resources may exist regardless of the other existing but they may reference each other
  • Dependent – one resource cannot exist without the parent
  • Associative – they are independent of each other but the relationship contains additional properties to describe it

Planning the Relationships

  • Ask yourself the following questions:
    • Can both resources exist without the other?
    • Does one resource only exist when the other exists?
    • Does the relationship between resources require more information than just the links between them?
  • It should be relatively easy to map out the flow, action, etc for each resource. If not, you need to revise your design.
  • Consider using notecards to write down each resource action

REST

  • REST stands for Representational State Transfer
  • It’s an architecture for designing network-based applications
  • It is not a protocol, framework, or standard

Benefits of Stateless Servers

  • Visibility – monitoring systems and developers do not need to look beyond the request to trace a bug
  • Reliability – easy to recover from system failures

Drawbacks of Stateless Servers

  • Network Bandwidth – client sends state for every request
  • Complexity – all clients must handle their states

Benefits of Caching

  • Performance – for stateless and caching, many requests do not need to go all the way to the server
  • Scalability – server gets fewer requests so it can handle more clients

Drawbacks of Caching

  • Data reliability – clients might use stale data

Facets of a Uniform Interface

  • Self descriptive messages
  • Server includes metadata, such as Content-Type, to help clients process the responses
  • Hypermedia as the engine of application state (HATEOAS)
  • Client only assumes a fixed entry-point to the API, the server tells clients all other available actions through hyperlinksBenefits of a Layered System
  • Encapsulation (simplify an interface to a legacy server)
  • Scalability (layers enable load balancing)
  • Security (add access control rules to data crossing a boundary, just like a firewall)

Drawbacks of a Layered System

  • Latency – adding layers increases latency
Posted on

Yoda Speak

I can’t believe it’s been nearly three weeks since I completed the WDI course. In an effort to make sure I’m staying sharp with my coding skills, I’m going to try to complete coding challenges every week and create a new app every month. Will I succeed with living up to those goals? I sure hope so!

I am also combing through my previous class assignments from WDI to try to find ways to refactor my code or polish existing work into more functional applications. So recently I decided to revisit a Yoda exercise we did. Using vanilla JavaScript, I created an application that utilizes the Yoda Mashape API for translating text into Yoda speak.

You can view the live app here and see the Github repo over here.

Yoda Speak

Posted on

WDI Day Forty: Project Week 3, Part 2

Today proved to be a day of frustration for my group – we’re struggling with Angular quite a bit. I managed to build up the back-end coupled with Angular as the front-end, however I’ve run into issues getting CRUD to function for the API. Update and show are working, it’s just a matter of getting delete and new to work.

After a day of struggling with my code, I’m on the verge of scraping everything and rebuilding. Sometimes you need to cut your losses.

Posted on

WDI Day Thirty-Seven: Angular, APIs, & Firebase

I’ve reached the conclusion that Angular is hard. It will take some getting used to with running through several exercises before I feel comfortable enough with it.

Today we worked with Angular alongside Rails. It was cool seeing how we can create our own APIs when we need to be able to work with updating the API data. It was weird seeing how Rails as the back-end fits together with Angular as the front-end. We walked through putting together a couple of single-paged applications with the Rails/Angular combo, and I noticed that the Angular server acts a little wonky at times when working on updates.

In the afternoon we walked through working on a SPA with Firebase. Firebase is a Platform as a Service (PaaS), that offers a number of cloud-based computing services, including a realtime database. Firebase uses Websockets to maintain a constant, open connection between the client and the database. We used AngularFire, which is a way to connect an Angular application to a Firebase DB.

Resources

Posted on

WDI Day Thirty-Five: API’s and AJAX

Earlier this year I took a class in JavaScript development, so API’s and AJAX are somewhat familiar to me. Today I realized that I have a much better handle on these topics when it comes to tackling new projects, however, I’m looking forward to practicing my work with API’s so that I can feel more confident with that type of code.

Application Program Interface (API) is a service that provides raw data for the public. We reviewed how we can create our own APIs so that we can use them for CRUD functionality in apps, which was a pretty fun scenario to take a look at.

Asynchronous Javascript and XML (AJAX) do server side requests asynchronously on the client without having to send an actual browser request that reloads the page.

In class, we played around with the following code to make API requests – and I thought it was a pretty good chunk of code that I could use for future reference when it comes to API-related projects:

$(document).ready(function(){
$("h1").on("click", function(){
var url = "https://api.wunderground.com/api/api_key/geolookup/conditions/q/va/midlothian.json"
$.ajax({
url: url,
type: "get",
dataType: "json"
// $.ajax takes an object as an argument with at least three key-value pairs...
// (1) The URL endpoint for the JSON object.
// (2) Type of HTTP request.
// (3) Datatype. Usually JSON.
}).done(function(){
console.log("Ajax request success!")
}).fail(function(){
console.log("Ajax request fails!")
}).always(function(){
console.log("This always happens regardless of successful ajax request or not.")
})
})
})