Working Towards RESTful Web Servies

working towards

RESTful Web Services

Friday, November 8, 13

GET /presenter/jessica
{
“name” : “Jessica Zehavi”,
“title” : “Software Engineer”,
“job” : {
“company” : “Clockwork Active Media”,
“href” : “http://www.clockwork.net”
},
“contacts” : {
“email” : “jessica@clockwork.net”,
“twitter” : “@yiska”,
“github” : “github.com/yiska”,
}
}


standards

turns out, it’s kind of hard


“A RESTful web service is an API
implemented using HTTP and
REST design principles.”
- Wikipedia (edited by me)


• Identiﬁcation of resources


• Manipulation of resources through
these representations



• Self-descriptive messaging



• Self-descriptive messaging
• Hypermedia as the engine of

application state (HATEOAS)


Identiﬁcation of Resources


• Resources can be anything!


• URLs identify resources
http://www.example.com/projects/
http://www.example.com/projects/1
http://www.example.com/deliverables/42


• URLs identify resources
http://www.example.com/projects/
http://www.example.com/projects/1
http://www.example.com/deliverables/42

• The representation describes the
resource’s state


Manipulation of Resources through
Representations
Project Represented in JSON
{

}


"id" : 1,
"name" : "Focus Media Group Project",
"start_date" : "2013-01-01",
"end_date" : "2014-06-31",
"status" : "complete",
"deliverables" : [ 1, 2, 3 ],
"departments" : [ 3, 8, 14 ],
"created_on" : "2013-09-20"
"modified_on" : "2013-10-01"

Manipulation of Resources through
Representations
Project Represented in XML
<?xml version="1.0" encoding="UTF-8"?>
<project>

<id>1</id>

<name>Focus Media Group Project</name>

<start_date>2013-01-01</start_date>

<end_date>2013-01-01</end_date>

<status>complete</status>

<deliverables>

<item>1</item>

<item>2</item>

<item>3</item>

</deliverables>

<departments>

<item>1</item>

<item>2</item>

<item>3</item>

</departments>

<created_on>2013-09-20</created_on>

<modified_on>2013-10-01</modified_on>
</project>


Self Descriptive Messaging

Operation

HTTP

Create

INSERT

POST

Read

SELECT

GET

Update

UPDATE

PUT

Delete


Database

DELETE

DELETE

Create / POST

Create a New Project

Response

POST /projects/ HTTP/1.1

HTTP/1.1 201 Created
Content-Type: application/json

{

}

"name" : "Museum Site Redesign",
"start_date" : "2013-10-01",
"end_date" : "2014-01-31",
"status" : "new",
"departments" : [ 2, 8, 11 ]


{

}

"id" : 1,
"start_date" : "2013-10-01",
"end_date" : "2014-01-31",
"status" : "new",
"departments" : [ 2, 8, 11 ],
"created_on" : "2013-09-20",
"modified_on" : "2013-09-20"

Read / GET

Request a Resource

Response

GET /projects/1 HTTP/1.1

HTTP/1.1 200 OK
{

"id" : 1,
"start_date" : "2013-10-01",
"end_date" : "2014-01-31",
"status" : "new",
"departments" : [ 2, 8, 11 ],

"created_on" : "2013-09-20",
"modified_on" : "2013-09-20"

}


Update / PUT

Update a Resource
PUT /projects/1 HTTP/1.1
{

}


"start_date" : "2013-11-01",
"end_date" : "2014-02-28",

Response
HTTP/1.1 200 OK
{

}

"id" : 1,
"start_date" : "2013-10-01",
"end_date" : "2014-02-28",
"status" : "new",
"departments" : [ 2, 8, 11 ]

Delete / DELETE

Delete a Resource

Response

DELETE /projects/1 HTTP/1.1

HTTP/1.1 204 No Content


Hypermedia as the Engine of
Application State

?

HATEOAS!

You Know This
“The principle of connectedness: each web page
tells you how to get to the adjoining pages. The
Web as a whole works on the principle of
connectedness, which is better known as
‘hypermedia as the engine of application state,’
sometimes abbreviated HATEOAS.”
- Leonard Richardson & Mike Amundsen
RESTful Web APIs


Hypermedia!
GET /projects/1 HTTP/1.1
Response
HTTP/1.1 200 OK
{

}


"href" : "http://www.example.com/projects/1",
"id" : 1,
"start_date" : "2013-10-01",
"end_date" : "2014-01-31",
"status" : "new",
"deliverables" : {

"href" : "http://www.example.com/deliverables",

"items" : [ 4, 5, 6 ]
},
"departments" : {

"href" : "http://www.example.com/departments",

"items" : [ 3, 8, 14 ]
},
"created_on" : "2013-09-20",
"modified_on" : "2013-09-20"

Common Mistakes

• Ignore hypermedia
• Using the wrong HTTP method
• Return the wrong response codes


APIs for Public Consumption

• Follow accepted standards/practices
• Consume your own API
• Versioning?


Implementation

• Resources
• Relationships
• Endpoints


Project Viz Application
• Tracks projects, resources and phases
• Complex and evolving requirements
• Wanted to host it themselves
• Super fast deadline!


// Get all projects
Route::get( 'projects', function( )
{
$projects
= Project::all( );
return Response::json( $projects );
});
// Get a project by id
Route::get( 'projects/{id}', function( $id )
{
$project = Project::find( $id );
if ( ! $project ) {
App::abort( 404 );
}
return Response::json( $project );
} )->where( 'id', 'd+' );


Response
HTTP/1.1 200 OK
{

}


"id" : 1,
"start_date" : "2013-10-01",
"end_date" : "2014-01-31",
"status" : "new",
"departments" : [ 2, 8, 11 ],
"created_on" : "2013-09-20",
"modified_on" : "2013-09-20"

// Create new project
Route::post( 'projects', function( )
{
$project = new Project( Input::get( ) );
$project->validate( );
if ( ! $project->save() )
{
App::abort( 500 );
}
return Response::json( $project, 201 );
});


Response
HTTP/1.1 201 Created
{

}


"id" : 1,
"start_date" : "2013-10-01",
"end_date" : "2014-01-31",
"status" : "new",
"departments" : [ 2, 8, 11 ],
"created_on" : "2013-09-20",
"modified_on" : "2013-09-20"

// Update project by id
Route::put('projects/{id}', function( $id )
{
$project->fill( Input::get( ) );
$project->validate( );
if ( ! $project->save( ) )
{
App::abort( 500 );
}
return Response::json( $project );
})->where( 'id', 'd+' );


Send
{ "end_date" : "2013-12-31", status : "active" }
Response
HTTP/1.1 200 OK
{

}


"id" : 1,
"start_date" : "2013-10-01",
"end_date" : "2013-12-31",
"status" : "active",
"departments" : [ 2, 8, 11 ],
"created_on" : "2013-09-20",
"modified_on" : "2013-10-26"

// Delete a project by id
Route::delete( 'projects/{id}', function( $id )
{
$project->delete( );
return Response::json( null, 204 );
})->where( 'id', 'd+' );

Response
HTTP/1.1 204 No Content


Do These Things

• Try to be RESTful
• Consume your own APIs if possible
• Write Unit Tests


Future!
• Rate limiting
• Authentication
• Hypermedia
• Versioning


kthxbye


Working Towards RESTful Web Servies

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (17)

En vedette

En vedette (7)

Similaire à Working Towards RESTful Web Servies

Similaire à Working Towards RESTful Web Servies (20)

Dernier

Dernier (20)

Working Towards RESTful Web Servies