Download to read offline
![Part I – API Overview – Data structure
JSON – described in RFC 4627
String:
“this is a string”
List:
[1,2,3]
Object:
{“key”: “value”}](https://image.slidesharecdn.com/birdeyeviewonapidevelopment-v1-151207075045-lva1-app6892/75/Birds-Eye-View-on-API-Development-v1-0-8-2048.jpg)
![Part I – API Overview – Data structure
JSON – described in RFC 4627
String:
“this is a string”
List:
[1,2,3]
Object:
{“key”: “value”}](https://crownmelresort.com/image.slidesharecdn.com/birdeyeviewonapidevelopment-v1-151207075045-lva1-app6892/75/Birds-Eye-View-on-API-Development-v1-0-8-2048.jpg)
Uploaded byAPI Talent
Birds Eye View on API Development - v1.0
The document provides an overview of API development, covering definitions of APIs and REST, HTTP methods and status codes, data structures like JSON, and authentication methods. It then discusses options for building APIs on AWS, including using Elastic Beanstalk for a Java-based demo API that returns a greeting when a name is passed as a path parameter. The presentation includes demos of server-based and serverless APIs on AWS.
More Related Content
Similar to Birds Eye View on API Development - v1.0
Birds Eye View on API Development - v1.0
- 1. Birds Eye Viewon API Development 7 December 2015 Presenter: Sebastian Krueger – Co-Founder and Technical Director at API Talent
- 2. Agenda • Part I:API Overviews • Definition • REST • HTTP • Data structure • Versioning • Authentication • Part II: Building APIs on AWS • Demo: Server-based APIs on AWS • Demo: Server-less APIs on AWS
- 3. Part I –API Overview - Definition A collection of endpoints to interact with an application. Internal and External APIs. This talk is all about External APIs. Different architectures: • XML-RPC • REST • SOAP
- 4. Part I –API Overview - REST Representational State Transfer Architectural properties • Performance • Scalability • Simplicity • Modifiability • Visibility • Portability • Reliability Architectural constraints • Client-server • Stateless • Cacheable • Layered system • Code on demand (optional) • Uniform interface https://en.wikipedia.org/wiki/Representational_state_transfer
- 5. Part I –API Overview - REST Uniform interface • Identification of resources • Manipulation of resources through representations • Self-descriptive messages • HATEOAS (Hypermedia As The Engine Of Application State) Resource as URIs – http://api.co/cars/123 JSON / XML / CSV HTTP GET, POST, PUT, DELETE mediatypes, cacheability, etc Hypermedia APIs HAL, JSON-LD, Siren, etc
- 6. Part I –API Overview - HTTP HTTP methods - URIs for collection/item http://api.co/v2/cars/ http://api.co/v2/cars/123 GET List all the cars Retrieve an individual car POST Create a new car ERROR PUT Replace the entire collection with a whole new list of cars Replace of create an individual car DELETE Delete all the cars Delete an individual car
- 7. Part I –API Overview - HTTP HTTP Status Codes Popular codes: • 200 OK • 301 Page Moved Permanently • 404 Page Not Found • 418 ? (RFC 2324) https://en.wikipedia.org/wiki/List_of_HTTP_status_codes http://restlet.com/http-status-codes-map https://http.cat/
- 8. Part I –API Overview – Data structure JSON – described in RFC 4627 String: “this is a string” List: [1,2,3] Object: {“key”: “value”}
- 9. Part I –API Overview – Data structure How to Read an HTTP Response
- 10. Part I –API Overview – Data structure How to Read an HTTP Response JSON RFC Collection+JSON Standard for publishing a searchable list of resources over the Web. Collection+JSON is a way of serving lists—not lists of data structures, which you can do with normal JSON, but lists that describe HTTP resources.
- 11. Part I –API Overview – Data structure How to Read an HTTP Response
- 12. Part I –API Overview – Data structure http://jsonapi.org/
- 13. Part I –API Overview – Data structure
- 14. Part I –API Overview - Versioning • Most frequent, in the URL: https://api.co/v2/cars/123 • Custom header: X-API-Version: 2 • Less frequent, with an accept header GET / cars Accept: application/vnd.cars.v2+json Clients don’t have to change endpoint, but update headers
- 15. Part I –API Overview - Authentication • HTTP Basic • Easy to implement. Least secure. • Always use SSL/HTTPS with base64 encoded username/password. • JSON Web Tokens • Send credentials to login endpoint • Endpoint returns JWT token • Send token with every request • OAuth2 • Most popular • Similar to JWT • http://oauthbible.com/
- 16. Part I –API Overview – Description Language
- 17. Part II -Building APIs on AWS What about the Runtime?
- 18. Part II -Building APIs on AWS There are a many options: • Roll your own (raw EC2) (could use AWS CodeDeploy) • Docker / AWS Elastic Container Service • AWS OpsWorks • AWS Elastic Beanstalk • AWS API Gateway / AWS Lambda Use 3rd Party PaaS (on top of AWS): • Heroku, Cloud 66, etc, etc, etc
- 19. Elastic Beanstalk ina Nutshell • EC2 Server • + Linux • + OpenJDK • + Tomcat • Scaling Elastic Load Balancer / Auto Scaling • Deploy artefacts on S3 • Can add database (RDS)
- 20. Let’s build aJava-based Web API DEMO TIME GET http://somewhere/hello/seb Returns: “Hello seb”
- 21. Thanks For YourTime Sebastian Krueger – Director of Cloud Engineering – API Talent Limited email: sebastian.krueger@apitalent.co.nz tel: +64 21 131 84 97
Editor's Notes
- #5 Stateless, Resource-Based Architecture No cookies. No sessions. Uniform interface. Typically, but not always HTTP. Not a protocol. It’s a set of properties and constraints. https://en.wikipedia.org/wiki/Representational_state_transfer
- #6 Stateless, Resource-Based Architecture No cookies. No sessions. Uniform interface. Typically, but not always HTTP. Not a protocol. It’s a set of properties and constraints. https://en.wikipedia.org/wiki/Representational_state_transfer Hypertext As The Engine Of Application State (HATEOAS) is a big part of REST. Its purpose is to add discoverability to your API. You can compare this to hyperlinks on regular websites. For example: imagine a Twitter feed, it consist of a long list of tweets sent by users. if you click on a tweet you get a detailed view of the tweet with all its responses. This is comparable with the HATEOAS structure. You attach a link to each entity in a collection, this link points to the endpoint of the specific resource. Why is this handy? In theory this allows dropping separate documentation. You don't have to document all your endpoints, the endpoints provide them themselves. In practice I would advise to always provide separate documentation.
- #7 HTTP is request/response driven, this means that a response only is given as a request is made. There is no constant stream of data (sockets). In HTTP the client sends verbs in the header of request, the server responses with HTTP codes in its response header. Now this is one of the hard parts about building an API, what verb fits with what action and/or what response code should be send. As far as the verbs go, only the edge cases are difficult, the response codes on the other hand are often open for discussion. So let's have a quick look at some commonly used ones.
- #8 http://tools.ietf.org/html/rfc2324 2.1.1 Coffee pots heat water using electronic mechanisms, so there is no fire. Thus, no firewalls are necessary… 2.3.2 Any attempt to brew coffee with a teapot should result in the HTTP error code 418 I'm a teapot…
- #10 The ETag or entity tag is part of HTTP. It is one of several mechanisms that HTTP provides for web cache validation, and which allows a client to make conditional requests. This allows caches to be more efficient, and saves bandwidth, as a web server does not need to send a full response if the content has not changed. ETags can also be used for optimistic concurrency control,[1] as a way to help prevent simultaneous updates of a resource from overwriting each other.
- #21 Maven Jersey